Irreal

The comments to my recent post Emacs And Modal Editing veered off to a discussion of why it’s not really possible to compare Emacs and Vim. Ag ibragimov expressed a point of view that I’ve long held: Emacs and Vim are really two different type of applications so it makes no sense to compare them.

I have always said that whether you embrace Vim or Emacs is a matter of your world view regarding editors. If you are looking for a fast, relatively light weight editor that excels in editing text and doesn’t bother with anything else, Vim is the correct choice. If you are looking for a Lisp Machine-like operating environment that serves as the center of your computing workflow, then you should choose Emacs. They’re both really good editors and which is right for you depends on that worldview.

All this was in the context of the editor wars, one of our oldest and most cherished holy wars. As I’ve said many times before, the editor wars can be funny and are often a source of entertainment but you shouldn’t take them seriously. These days, I doubt anyone does.

That brings us to this post by Odd-Distribution2887 from the Emacs subreddit. His worldview, I submit, is clearly that of the Vim user and he would probably be happier there. He appears to think that he should want to use Emacs but why should he? He should use whatever editor is in most accord with his workflow and disposition.

That’s not to say it’s a lifetime commitment. You can, and lots of folks do, change their mind and switch from one to the other. I spent at least 25 years with Vi(m) before I changed to Emacs. If you’re interested, you can read my two part series on why I changed here and here.

The takeaway from this post is that neither Vim nor Emacs is “better”. It’s simply a matter of what you’re looking for in an editor.

Richard Stallman writes to announce that he’s appointed a new Emacs maintainer. Not to worry, Eli Zaretskii is still a maintainer but Andrea Corallo will now be a co-maintainer along with Zaretskii and Stallman.

Corallo, of course, is the engineer who brought us native compilation, inarguably a tour de force.
Whatever you think of RMS, he does have a good record of appointing excellent Emacs maintainers. As I’ve written recently, heading up Emacs development takes a lot of knowledge and work and I’m sure Eli can use a bit of help.

I extend my best wishes to Corallo and am confident that he will be another in a long line of excellent maintainers. You can consider this post as my thanks to him in advance. As I’ve said repeatedly, we all owe those who step up to take on this task a huge amount of thanks.

Over at the Emacs subreddit, meedstrom raises an interesting point: why is everyone hating on the Dash library? The short answer appears to be “dependencies”. Using the Dash library increases the number of dependencies and everyone knows that’s bad.

The slightly longer answer is that most of the Dash functions have—at least rough—analogs in the builtin libraries and thus using Dash increases the number of dependencies and everyone knows that’s bad.

I’m a huge fan of Magnar Sveen from his Emacs Rocks videos and other work on Emacs. I often find myself using his Dash library because its functions do just what I need doing in a simple way. That said, I’ve never once actually required the Dash library. That’s because it’s used by so many packages that it gets pulled in to just about every Emacs installation. Bad form, I know, but I don’t generally distribute my code so I never think to include Dash explicitly.

Increased dependencies or not, Dash is everywhere and no one that I know of has anything bad to say about its quality. So the argument against Dash boils down to: “Dependencies bad”. Meedstrom raises the heretical thought that maybe—at least in the case of Emacs—dependencies aren’t really a bad thing. He also notes that in order to get the same functionality you need not only the builtin libraries but another third party library (llama) anyway so the hating on Dash is really pointless.

You can read meedstrom’s post and decide for yourself but I find his argument convincing. In any event, Dash isn’t going anywhere so maybe all that negative energy should be redirected to a more deserving target such as … Well, you know.

Like many of us, James Dyer sometimes has to use Vim even though he’s a dedicated Emacs user. He does this often enough that he’d like to maintain a bit of muscle memory for the Vim navigation commands. He doesn’t want a full blown Vim emulation like Evil or even something like Meow so he rolled his own. His solution is (really) simple: he merely made a few remappings:

• Ctrl+b → Meta+h
• Ctrl+f → Meta+l
• Ctrl+n → Meta+j
• Ctrl+p → Meta+k

It would, of course, be easy to expand this. You do need to find other bindings for the ones yours stealing but at least in this case Dyer says he didn’t use them much anyway.

I know I’m always going on about muscle memory and the problems I have with trying to use two editors but even I have to use Vim sometimes and when I do I may struggle to remember the bindings but it’s mostly pretty easy. What I don’t want to do is rearrange all my Emacs bindings just to ease my occasional forays into Vim land. Of course, my travels over the wall are infrequent so perhaps I’d feel differently if I had to make the trip more often.

In any event, Dyer’s solution may point the way to a solution for those of you have similar problems. Take a look at his post if you, too, occasionally live in two worlds.

No, not that Sunrise, Sunset. This one. Today’s post is just a quickie on some already plowed ground. Eight years ago, I wrote about finding the times of sunrise and sunset from within Emacs. I thought it was sort of interesting but never did anything about it.

Now Charles Choi has resurrected the subject. He likes to walk in the evening and finds it useful to know when the sun will set. It turns out that this is easy to do from within Emacs. One more reason to never leave the comfort of our favorite editor.

The only wrinkle is that you have to know the latitude/longitude of your current location. On macOS, that’s easy to find. Just open the Map application and your current location will be marked on the map. Click on that and it brings up an information block that, among other things, tells you the lat/lon coordinates. I’m sure the process is similar on Google maps or whatever you use on your system.

I don’t really have any need for this because:

1. I seldom care about the comings and goings of the sun
2. The sunrise/sunset times are available from the Apple Weather app, which is just a hotkey (via Alfred) away.

Still, it’s good to be able to do as much as possible in Emacs so I added the lat/lon to my init.el and I can now query the sun’s appearance and disappearance right from Emacs. It’s especially nice to do it from the Org agenda. See Choi’s post for the details.

Charles Choi is on a roll. He discovered the trick of improving the interfaces to various Emacs functionalities by capturing them in a transient menu. I’ve already written about his considerable contributions to the usability of Calc: my last post is here.

Now he’s back with a nice interface to Dired. I do virtually ail my file operations with Dired but for whatever reason I don’t do a lot of them so whenever I want to do anything even slightly non-routine, I have to bring up the Dired cheat sheet, which I have bookmarked for easy reference.

Choi has solved that problem. Now a simple keystroke brings up the menu shown on his post and you can invoke any of the Dired functions right from the menu. Notice how it doesn’t get in your way. If you already know how to do something, you can just do it. If you can’t remember some command you can bring up the menu to invoke it and immediately return to your normal workflow.

I really like this package. It mostly stays out of your way but when you need it, it’s just a keystroke away. Doubtless Choi will make adjustments as he gains experience with the package but even now it seems like a win.

One of my everyday chores is to read through the Emacs and Org-mode mailing lists. I don’t read most of the posts unless they catch my interest but just checking the headlines gives me an idea of what’s going on. The other day, I saw this post asking why such and such a function was written in C rather than Elisp.

It’s a common question. Someone is reading through the source code, finds a function written in C, and thinks, “this code could/should be written in Elisp.” Everyone’s always complaining about the C core so why not reduce that C core as much as we can?

It turns out that it’s not just inertia as Eli Zaretskii tells us in his answering post. He explains in detail the problems that arise from making an apparently simple change like rewriting a function in Elisp. It’s not, as you might think, a worry about introducing a surface error due to the rewrite. It’s that the C core is available during the whole boot process but an Elisp function may not be so before rewriting a function in Elisp you have to make sure it gets loaded before any other function calls it. Sometimes that function, as the one under discussion, may be called from C, making it even harder to make sure it gets loaded before being called. See Eli’s post for a complete explanation.

Most of us, of course, wouldn’t think of all that. We’d merely say, “Yeah, of course, rewrite that sucka.” Those two messages gave me a renewed appreciation for Eli and the other devs who have to deal with keeping Emacs the world class editor that it is. It’s easy to think they’re just being overly conservative but it turns out they have good reason for their caution.

So I’d like to take a moment to thank all the devs for bringing their deep knowledge and caution to the task of keeping Emacs running. It’s harder than it seems.

Over at the Emacs subreddit, TheTwelveYearOld asks an interesting question: Would Emacs be more popular than Vim if it used modal editing by default? Experienced users will recognize that there’s an unstated premise buried in the question. The premise is that modality is what separates Emacs from Vim and that that modality is responsible for Vim’s greater popularity. That is, I think, a flawed premise. Vim’s real strength, in my opinion, is not modality but the regularity of its command set.

TheTwelveYearOld’s post has some other misunderstandings but the interesting thing about it is the comments. Most of those comments take issue with the notion that Vim’s popularity is due to its modality. Almost all of them ascribed Vim’s popularity to its ubiquitousness. If you log on to almost any Unix system, Vi(m) will be there so it made a lot of sense for students and beginners to learn it and make it their go to editor.

Most of the comments dispute that either editor enables faster editing than the other. Several commenters noted that both editors use about the same number of keys to do any given task. There were a lot of good, interesting, and informed comments and they’re well worth reading.

For me, the most shocking, or perhaps sad, comment was from ilemming who said,

Until the Emacs development model shifts away from its exclusive focus
on super-smart nerds and starts accommodating regular coders, it is
likely to remain less popular and may struggle to introduce new
game-changing features on a regular basis.

The idea that Emacs is only for the super smart seems to me to be self-revelatory. Emacs is not, of course, a tool restricted to the “super smart” and thinking so says more about the person saying it than it does about Emacs. If you’re a developer and find Emacs, or any other editor for that matter, too hard to master, you should find another line of work.

In any event, the post and the comments are an interesting part of the never ending editor wars.