Irreal

One of the problems faced by those of us who have moved our email operations into Emacs is how to download the emails from the Imap server. There are two popular solutions: offlineimap and mbsync.

Offlineimap is written in Python and has the reputation of being slower than mbsync, which is a C application. Occasionally you see this disputed by someone offering largely anecdotal evidence that there’s no discernible difference. Such claims are invariably met with other anecdotal evidence that mbsync is indeed faster.

Charl Botha, who’s postings on email in Emacs have been excellent, decided to offer some actual scientific evidence so he ran some timing tests. The tests were all run on a single Windows 10 machine so they are by no means a definitive benchmark but they do offer much better information than we had before and probably generalize to the other platforms.

I’ll let you head over to Botha’s site to get the actual results but the TL;DR is that mbsync’s running time for a sync is about 65% that of offlineimap’s normal mode. Offlineimap, however, also has a quick mode that may not detect some message flag changes but that runs at about the same speed—a little faster, actually—as mbsync.

I don’t think any of this matters much. Generally the syncs are happening in the background so you don’t really notice them unless you’re forcing a sync. Even then, the times are not onerous. As for offlineimap’s quick mode, I think life is already uncertain enough without adding additional entropy to solve a problem that has another, better, solution.

I started off using offlineimap but changed to mbsync because I read reports of instability on offlineimap’s part. I never experienced that so it was probably just irrational paranoia. I don’t know if it’s still true—or ever was, for that matter—but I’ve been happy with mbsync and it was difficult enough to get configured that I have no desire to change.

Over at the Emacs sub-reddit, yep808 says that he thinks of Emacs not as an editor but as an editor framework that allows you to build the editor you really want. He asks if others share this view. It is, of course, a widely held perspective but as Irreal oldtimers know, not one that I think is precisely accurate.

My view is neatly captured by rhabarba’s comment which posits that, “GNU Emacs is a Lisp machine emulator which can (but does not have to) start a text editor application by default.” I’ve long held that the real power of Emacs comes from that fact: that Emacs is, in fact, a light-weight Lisp Machine.

Sadly, it’s nowhere nearly as powerful (a software system) as the original Lisp Machines but it does allow us to do all sorts of non-editing things like using it as an RSS reader, or music player, or Email client, or any number of other things. And, of course, we can easily build our own applications in Emacs Lisp.

It might seem as if it doesn’t matter how you view Emacs but I believe thinking of it as a Lisp Machine has a definite benefit: it encourages the view that Emacs is a programmable environment in which you can build all sorts of applications that are only peripherally, if at all, related to text editing. Once you adopt that point of view, you can start really tapping into the power of Emacs by writing code to solve your own problems.

One of the (legitimate) complaints about Emacs is that it doesn’t do very well with excessively long lines. Happily, this isn’t a problem for me. I write my blog posts with visual line mode enabled and fill disabled so Emacs sees each paragraph as a single line. Despite that, I never run into problems so it’s not a issue for many (or perhaps even most) users.

Still, if it does effect you, it can be a real annoyance: Emacs can take a considerable amount of time to render the text. Happily, help is on the way. A fix for the long lines problem has been added to the 27.1 Master branch. Some early 27.1 adopters are reporting excellent results with the fix.

If you follow the link at the top of reddit link above, you will see the documentation for the changes. It’s worth reading that to get a feel for how the changes will affect working with long lines.

This change should—but probably won’t—put to rest the notion that Emacs is an old, moribund editor still alive only because a few gray beards refuse to let go. It shows that development is strong and on-going and even long standing issues are being worked on and resolved.

As I’ve written many times, one of my most used and useful packages is abo-abo’s Ivy/Counsel/Swiper suite. Happily, he is always tweaking it, making it better with each iteration. He latest tweak rethinks the reverse i-search command (Ctrl+r) used in Bash. The problem, he says, is that you have to invoke Ctrl+r repeatedly while you search for the command you want.

Abo-abo applies the Ivy UI to this action so that you get a list of possible completions that can narrowed in a fuzzy manner. That’s great for when you’re in shell mode but abo-abo, of course, brought the functionality back to Emacs itself so that you can, for instance, use it when opening a file with counsel-find-file.

The updates are already in Melpa so if you’re up-to-date with your packages, you can start using the functionality immediately. You’ll need to set a couple of key bindings but that’s all. Take a look at abo-abo’s post for the details of setting things up.

As I’ve written before—most recently here—if you haven’t yet tried Ivy/Counsel/Swiper, you owe it to yourself to give them a try. Different people like different things, of course, but it’s hard for me to see why anyone wouldn’t like the Ivy/Counsel/Swiper suite. Helm users have basically the same functionality but Ivy and friends are a bit lighter weight and at least one Helm user that I know of switched after trying Ivy out.

I was a bit put off by this tweet:

I know that cool kids don’t use #emacs, but I love it. And also even if the last guide isn’t that complete, it still a fast starting point for those who already know emacs and don’t want to read a full tutorial to setup it for C.

— LIBRENEITOR (@libreneitor) July 2, 2019

The problem isn’t LIBRENEITOR, who is, after all, an enthusiastic Emacs user despite what the cool kids say or do. My problem is with the notion that the “cool kids” don’t use Emacs.

I don’t think it’s true. At least not for any reasonable definition of “cool kids.” But suppose it is true. Who, then, are the cool kids? I submit that by and large they are just like the cool kids in high school who ended up pumping gas after graduation. In modern terms, they are the hipsters. Or to put it a third way, they are unserious people.

If you’ve been around Irreal for a while, you know what tools I think serious developers prefer. Maybe that’s just because I’m an older developer and don’t know any better but it seems to me that people who wax rhapsodic about editors like VSCode or Atom always say the same thing: “It’s so much prettier than Emacs.” They never claim that they’re more powerful because, of course, they’re not, just that they’re prettier. I agree with Vivek Haldar: “why should you ever care how your editor looks, unless you’re trying to win a screenshot competition?”

Sadly, even Emacs users can be affected by this silliness. Consider this reddit post bemoaning that out-of-the-box Emacs is so ugly. Notice that the complaint isn’t about lack of functionality; it’s about appearance. Experienced Emacs users get rid of as much appearance as they can. They disable the tool bar, the menus, and the scroll bar. They value usable screen real estate over eye candy and they certainly don’t want to have to use the mouse. And by the way, light themes are better; it’s science. You don’t want to be a science denier, do you?

By now many of you probably have a mental image of me waving a cane and yelling at kids to get off my lawn. That’s probably not entirely unjustified but I do wish folks would treat their editors as tools to be valued for their functionality instead of as an extension of their wardrobes.