Irreal

Over at the Emacs reddit, Gink0 asks What dev feature is available in emacs but not in the current mainstream IDEs? It’s sort of like the usual question of “What makes Emacs so great?” or “Why do you recommend Emacs?” but with the added constraint that it has to be things that other editors don’t have.

For me, the salient feature is that Emacs provides the closest thing we have to a modern light-weight Lisp Machine. It’s not the “Lisp Machine” part that matters, of course, it’s what “Lisp Machine” is shorthand for: a complete, totally, configurable, and even reprogrammable operating environment. That means that can do just about anything you do on a computer in Emacs and do it with a unified interface.

Many of the responses to Gink0 hinted at this but emphasized the configurability that Emacs has far in excess of other editors. Other responses mentioned Org mode and its enabling of literate programming. Other editors may support literate programming to varying degrees but Org mode’s code blocks are special. Not only can you have traditional literate programming in the Knuth sense but you can also embed executable code in an Org file and have the results of running that code appear in the file. It’s tremendously powerful regardless of whether or not you like Knuth’s version of Literate Programming.

Those are the big things. Some of the commenters mentioned smaller things such as narrowing, rectangular editing (although lots of editors have that), the best Vim emulation, undo tree, Eshell, and the notion of modes.

What’s on your list?

Mike Zamansky has the third video in his Learning Elisp series up. As promised, this one is about writing functions. As Zamansky points out, Elisp functions are pretty much the same as function in other languages except for the lack of a return statement and, of course, the syntax.

There are a couple of interesting aspects to Elisp functions. The first is the Doc String. Lots of languages have something similar but in Emacs the Doc String is automatically imported into the Help system so a user’s own functions are documented just like the built-in functions.

The second aspect is the interactive declaration. Including it makes the function “interactive”, which means that you can call it from the keyboard with Meta+x or by assigning it a key binding. My goal for writing Elisp is to write an interactive function where I remember to add the interactive declaration before I try to run it from the command line.

The video covers just the very basics of writing functions. Zamansky is planning on getting into some of the deeper aspect in later videos. This video is 12 minutes, 36 seconds long so you’ll probably have to schedule some time.

Mike Zamansky has posted his second Learning Elisp video. In this episode, he briefy discusses defining variables, both global and local. The rules are a bit different from most other languages but still simple enough to understand easily.

In keeping with his taking things slowly, he doesn’t mention the closely related concept of closure but presumably that will come after he’s laid a bit more groundwork. If you have any experience at all with Elisp, nothing in this video will be new but it’s just what a n00b needs to get started.

He was originally going to include functions in this video but decided it would be too long so he decided to defer functions to the next video. Once that’s done, his plan is to move into the “interesting stuff” and show how to use Elisp to write interesting and useful functions.

The video is 11 minutes, 58 seconds long so plan accordingly.

As most of you know, I’m a Mu/Mu4e user and have been very happy with it. It has, I think, the correct paradigm for handling stored email: everything goes into a single repository and emails are retrieved with its outstanding search capability. Stored messages are indexed so these searches are very fast. You can, of course, use the normal method of multiple mailboxes but why would you?

Another of Mu’s benefits is that it runs in Emacs. That’s a benefit that it shares with Notmuch a similar package that has excellent search and indexing too but also implements a tagging workflow.

Michał Sapka was tired of using Webmail because of its inflexability. He used Neomutt for a while but decided he’d like to fold his email into Emacs. He quickly settled on either Mu/Mu4e or Notmuch and—apparently randomly—chose Notmuch. That was a good choice for him because his workflow includes working with GitHub Pull Requests and he brilliantly leverages Notmuch’s tag system to automate it as much as possible. He goes into detail on how his workflow functions so be sure to take a look at his post.

Another nice thing about his post is that gives an excellent explanation on how to configure Mbsync. If you’ve been around Irreal for a while, you may remember that that was the thing I had the hardest time with when I moved to Mu4e. It’s definitely a worthwhile post if you want to move your email to Emacs.

Dmitriy Pshonko has an interesting project for those of us who like to (a) stay in Emacs and (b) use the mpv media player. The idea is that you can list your media files with dired and it will tell you where you left off in the file if you started but did not complete it. Files that you’ve completed are marked done and the rest are simply listed.

I almost always consume these files in one sitting but sometimes I get interrupted and it would be nice to have a way of picking up where I left off. I don’t use mpv so I haven’t installed this package but if I did use mpv, I certainly would. It’s in MELPA so installation is simple and configuration consisted of setting a hook. The README explains how to do this directly or with use-package and is in any event a one liner.

If you’re an Emacs and mpv user, this package seems like a very nice addition.

I ran across a post by James Dyer, Dired Duplicate Here Revisited, that was interesting and I thought was worth writing about but I wasn’t sure there was enough there for a post. Then I saw this post by Álvaro Ramírez and thought they complemented each other and together can serve as the basis for my own post.

It turns out that Ramírez had the same thought and that his post was inspired by Dyer’s. It started with Dyer wanted a quick way to duplicate a file in a Dired buffer. His workflow results in a frequent need to do this so it made sense to make it as frictionless as possible. His code to do this is simple and straightforward.

Ramírez, of course, extended the idea by including it in his dwim-shell-command framework. He uses Bozhidar Batsov’s crux-duplicate-current-line-or-region that duplicates a line or region. It’s similar to Joe Casadonte’s and Steve Purcell’s whole-line-or-region that I use. In any event, he leveraged his muscle memory for that by using it to invoke his dwim-shell-command template to duplicate one or more files in a Dired buffer.

If you also have a need to duplicate one or more files in a Dired listing, take a look at these two posts. They present two excellent solutions.

Charles Choi has another thought provoking post: this time it’s about Emacs defaults. He begins by noting that Emacs exemplifies the idea that you should separate policy and mechanism by providing a mechanism but leaving the actual policy to the end user. Put another way, Emacs allows the user to determine how certain functions will behave. That’s tremendously powerful and liberating.

The problem, he says, is the default policies. For any given action—whether or not it’s configurable—Emacs has to something and that something is the default policy. Choi’s complaint is that the default very often violates the principal of least surprise. I’d screw down on that by saying it violates the principal of least surprise for today’s users. Things like the CUA conventions are what new users might expect but not what long term Emacs users expect. The right thing for new users is probably to enable the CUA bindings by default but that would confound and anger long term users. My point is that it’s not as easy as doing “what people expect”.

The majority of Choi’s post is devoted to default choices with which he disagrees. Most are hard to argue with. There’s no reason, for example, why bookmarks shouldn’t be saved immediately rather than risking them in an Emacs crash.

Some, such as the number of spaces ending a sentence are not as straightforward as he and others imagine. Yes, we are no longer using typewriters and the original rationale for using two spaces no longer applies but, again, old time users may expect the two space rule. Even those who’ve never used a typewriter can make a coherent case for it: it’s easier to write scripts and distinguish end of sentences from things like “Mr. Jones” if sentences end in two spaces. This is a raging question even outside the Emacs community.

In others, such as Magit prompting you if you have an unsaved buffer that might effect the current operation, I think he’s just plain wrong. Almost every time I see that prompt it’s because I have, in fact, neglected to save a buffer. Of course, we all have different work flows so you may disagree.

Finally, his suggested defaults includes some useful things that I didn’t know about. For example, I run Emacs in full screen, which means that when I run Ediff the control panel is not visible. Choi explains how to fix this. similarly, when you invoke Man, the focus stays in the current buffer making it hard to negotiate the man buffer. Again, this is configurable and it seems to me to make more sense to do as Choi recommends.

It’s a good post and you may even learn something useful like I did.