Irreal

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.

Irreal is always gathering examples of why and how Emacs can help you in your coding and writing endeavors. Regular features of those examples are Org mode, Magit, and, more recently, LSP. It wasn’t always like that. I’ve only been using Emacs for about 17 years but even I can remember not having Org or Magit.

Still, even in those prehistoric days there were plenty of reasons to use Emacs. Back in 1991, Bob Weiner wrote a paper on why you should use Emacs. A lot of the things we take for granted were not yet available. There was Dired and Gnus but the idea of Emacs as an environment you could live in was still nascent.

His paper made me realize that as nice as things like Org and Magit are, they aren’t the reason you should be using Emacs. Rather, it’s the core editing and file management capabilities that make it so useful as an editor. At the end of the day, it’s all about writing your code or prose as efficiently as possible, and Emacs excels at that.

It’s interesting to read about the reasons to use Emacs before the more recent functionalities were added. As nice as those functionalities are, Emacs is really all about efficient editing. That’s why they call it an editor.