Irreal

Lots of people recommend Evil mode or switching to a Dvorak keyboard because it allows for more efficient editing. Evil mode is probably more efficient and, more importantly, helps with RSI problems. As a long term Vi/Vim user, those bindings were burned into my muscle memory and when I switched to Emacs and decided to use the vanilla keybindings, it was hard to give them up. Still, the default Emacs binding are also pretty efficient and the ability to easily implement my own editing commands more than makes for the loss of composability. The bottom line is that I’m pretty much agnostic concerning Evil mode.

Then there’s Dvorak and similar keyboard layouts. After suffering the pain of learning to touch type with QWERTY, I have no desire to start again for a possible gain of a few words a minute. I’m pretty efficient with QWERTY and if I needed to up my speed, there are plenty of videos and tutorials to help with that. The bottom line is that I’m not going to adopt some new keyboard layout and the associated pain for a small, putative increase in typing speed.

That brings us to Devil Mode. The idea is to get rid of the modifier keys while avoiding modal editing. To do that, the comma key is used instead of the Ctrl key so that you would open a file with , x , f. There are, of course, ways of dealing with the Meta modifier as well.

Your first question is, undoubtedly, how do you type a comma? The common cases of a comma followed by a Space or Return work normally but you can use , , for the edge cases. Follow the link for all the details.

If you really really want to eliminate the modifier keys without embracing modal editing, Devil Mode may be worth checking out. For me, it seems more like moving to Dvorak: whatever gain you might get isn’t worth the pain.

Eli Zaretskii writes to say that the second pretest of Emacs 29.1 is available for testing. If you don’t mind living a bit on the edge, Zaretskii would be grateful for your testing and letting the developers know of any problems you find.

As always, thanks to Eli and the other developers for their hard work in readying this latest release for our use. They are truly heroes and we owe them all our gratitude and, should the opportunity arise, a beer.

Franco Pasut has an instructive post on how to diff files with Vim and Emacs. Both editors have very nice built-in functions to make diffing files easy. I’ve used them both and can attest to their utility.

Pasut’s post, Notes on resolving differences between two documents with the built-in resources of Vim and Emacs, isn’t a comparison and doesn’t make any value judgments. Rather, it merely shows how to use the two systems. I haven’t used Vimdiff in years but my memory is that it was easier to use than Emacs’ Ediff system.

Regardless of their relative merits, both are easy to use and very powerful. To see this, think about how you would reconcile two files with just the standard Diff program and some random editor. With Vimdiff and Ediff, you see the differences one by one and can choose which variant to keep. With Ediff, you can even edit the file directly.

If you’re not familiar with the two systems, take a look at Pasut’s post. It’s short and tells you more than enough to use either efficiently.

Abbreviations are a useful Emacs feature. They can do anything from inserting a non-ASCII character to changing “latex” into “LaTeX”. If you do a lot of writing they can be a significant timesaver. If you do any coding, you’re probably familiar with YASnippet, which can also do these things.

Regardless of what system you use, all the existing solutions suffer from being global or, at best, restricted to a given major mode. Sometimes, though, it’s convenient to have a set of abbreviations that are local to a given buffer and hidden when you change focus to another buffer. Chander G has recognized the need for local abbreviations and responded with lam—the Local Abbreviation Manager.

It’s a nice application. It’s simple to use and doesn’t require learning a lot of keybindings. One binding does everything you need and you set that to whatever is convenient for you. It also has the ability to run some Elisp after or instead of making the substitution. There’s an animated GIF at the GitHub site that demonstrates this.

It’s still early days for the project. It’s not yet in MELPA, although it is available for downloading. At the end of the README, there’s a list of additional features that Chander G is considering adding. They all seem reasonable and, most importantly, maintain the simplicity of the package.

If you think local abbreviations would be a win for your workflow, take a look at lam. It’s a single, short file so even without MELPA, it’s easy to install and maintain.

Jeremy Friesen has an interesting post that may teach you a couple of things you didn’t know. Friesen uses Org mode a lot in his writing and everything he writes and has lots of links—both standard and customized—in that writing. His problem is that he often wants to complete a word or symbol to a link that is already in the buffer.

On the one hand, I’m not at all interested in this post because I try never to link to something more than once in a single post. On the other hand, the post is still interesting to me because it provides a good go-by for how to obtain a list of (Org) links in the current buffer. That turns out to be harder and simpler than you might think. The solution is not to cycle through the buffer looking for the appropriate regex. Rather, the solution involves using org-element-map to find the links and generate propertized strings of the results. It’s a nice example of dealing with an Org buffer without falling back on regexes.

Friesen also presents some other code that shows how he does the actually completion if your interested in duplicating his workflow but even if you’re not the post has lots of good technical information. Even if you don’t have custonized links, you might find it useful.

UPDATE [2023-05-09 Tue 14:28]: In a subsequent post, Friesen explains his need to link to a resource multiple times.

Michał Sapka has an interesting post that serves as a nice coda to yesterday’s post on Emacs integrating so many productivity tools. One of those tools is the RSS feed reader, Chris Wellons’ Elfeed.

Sapka’s post is about his moving to Elfeed for his RSS feeds. His move is in the context of a larger migration from dedicated packages to those integrated with Emacs. Elfeed needs no justification other than its own excellence. It is, by far, the best RSS reader I have ever used and the fact that it operates under Emacs is just a bonus. You can check Sapka’s post for some of the things he likes about it but the TL;DR is that it’s simple and includes images when appropriate.

Contra Google, RSS is an important tool for many of us and having a first class reader integrated into our editor of choice is a huge win. FortunateDaughter_ from yesterday’s post, wonders if it’s worth it for users to prefer Emacs integrated apps in preference to dedicated applications performing the same functions. The unstated implication is that these dedicated applications are better. Elfeed puts the lie to that. It is, in my opinion, the best RSS reader at the same time it’s integrated into Emacs. It turns out that, sometimes at least, you can have it all.