Irreal

Over at the Emacs subreddit, iLemming has an interesting video that explores two packages by thanhvg for reading reddit and Hacker News from within Emacs. The two packages are emacs-reddigg and emacs-hnreader.

Both packages give you a nice Org buffer with each article as a heading and the rest of the content below. Watch iLemming’s video to see them in action. It’s also pretty easy to customize them as iLemming shows by providing custom search functions. Again, take a look at the video for more details.

I like these two packages but, sadly, they don’t fit into my workflow. I never read reddit or Hacker News directly. Rather, I get their content through elfeed, which has a similar user interface and look. Of course, elfeed is RSS based so I often have to follow the link to get all the content. Since I have WebKit hooked into elfeed, my actual workflow just shows we the original Web pages directly as I view each entry.

Of course, lots of people do read reddit and Hacker News directly, and for them these two packages are ideal. You can follow both sites from the comfort of Emacs. If you’re one of those people, take a look at iLemming’s video and see if they might be right for you.

Just in case you haven’t heard enough whining about Emacs not having “modern” keybindings, arthurno1 over at the Emacs subreddit has a long post on possible ways to reconfigure Emacs to get them. It’s an interesting post because arthurno1 actually considers ways to solve the problem rather than just complaining that Emacs keybindings aren’t what he’s used to¹.

The problem turns out to be more difficult than you might think. It probably explains why there isn’t a set of “keybinding themes” similar to the display themes that we have.

I should be more sympathetic to those wanting Emacs to use conventional keybindings. After all, I’ve admitted several times that I have a hard time using multiple keybindings. But when I thought about it, I realized my problem is with using multiple keybindings for they same type of application. For example, I would have a hard time using both Emacs and Vim, even though I know them both well because my muscle memory would cause me to use the wrong binding for a given operation. I have no problem using different keybindings for different apps. So, for example, it doesn’t bother me at all to use Ctrl+s for search in Emacs and ⌘ Cmd+f for the same operation in Safari. Of course, since I mostly live in Emacs, even different keybindings among applications isn’t much of a problem.

I suspect, though, that a lot of this yearning for “modern” keybindings really means, “I want it to be like VS Code” or whatever other editor they’re used to. For those people, I can do no better than to channel Dennis Ritchie: If you want VS Code, you know where to find it.

Some folks like to see a visual indicator of the file type in file listings. In Emacs, this usually means in the Dired listings. Probably the best known way of doing this is the all-the-icons-dired package. It has a set of beautiful icons that it adds to each entry to identify the file type. The problem, from some people’s point of view, is that all-the-icons-dired is a third party package and may, in turn, require the installation of additional font files.

James Dyer likes the idea of a visual file-type indicator but doesn’t like having to deal with external packages and their dependencies. His solution is a light-weight version of a visual icon package. Actually, it’s not even a package, just a bit of code that you can add to your init.el to implement his solution.

The “icons” are just standard shapes that are in virtually all font sets. They aren’t as pretty as those in all-the-icons-dired but they do serve to provide a visual indicator of file type. The shapes are listed in a simple variable so you can change them to suit your needs.

Being an old-time guy who spent a lot of years working on text terminals, I have no problem distinguishing file types by their extension—which is, after all, what all these packages do—so I don’t feel the need for such a solution but if the idea appeals to you and you don’t want to deal with dependencies, give Dyer’s post a look. It’s simple to try out and if you don’t like it you can just delete the code from your init.el.

The joke about Emacs being an operating system is an old one but lately the idea seems to be being taken more seriously. Here’s the latest example. Significantly, the poster, Bi-Jean, is a self-confessed n00b who doesn’t work in the tech industry, just someone who likes playing with computers and is curious about the best ways of using them. The idea seems natural to Bi-Jean.

If you believe, as I do, that the best way of thinking of Emacs is as a latter-day Lisp Machine, the idea of it being an OS makes more sense. Specialized applications aside, there’s basically no function that you can’t implement from within Emacs except arguably a decent Web browser. From that perspective, the “real” OS is viewed as a set of device drivers for Emacs. It’s a point of view adopted by many Emacsers who claim not to care what OS it’s running on.

My own view, as someone who does almost everything from within Emacs, is that “My operating system is Emacs and Linux/macOS/Windows is just a set of device drivers” is a nice joke that captures an underlying truth but isn’t truly realistic. I always say that I do virtually everything in Emacs and Safari but the “virtually” provides a little wiggle room. For example, I use Fantastical to sync my calendar across all my devices, the Reminders app to set a reminder across all my devices, and the Apple Messages app for texting—although I do use Emacs to compose the text—so it’s not really Emacs all the way down.
Still, a case can be made that in an essential way, Emacs really is my OS. Perhaps more important is the fact that it doesn’t really matter. I do most of my work—other than browsing—from within Emacs and if that makes Emacs my operating system, fine but I also depend on macOS for more than just running Emacs.

I’ve written several times about Álvaro Ramírez’s DWIM tools [1, 2, 3, 4, 5, 6] and their use in easily invoking command line utilities from the comfort of Emacs. Ramírez has a large collection of such utilities built on the DWIM Tool framework but I’ve never seen anyone else use it for their own work.

Now JTR over at The Art Of Not Asking Why has a post that describes his own use of DWIM Tools. JTR wanted to compress videos while preserving their resolution. That’s pretty easy to do using FFmpeg and JTR knew how to do it but he decided to see if he could use DWIM Tools for the job.

It turned out to be pretty easy as you can read at JTR’s post. The lesson I take from this is not that there’s another application available under the DWIM Tools umbrella but that it’s pretty easy to add one. If you have some command line utility that would be convenient to invoke from within Emacs, you should take a look at DWIM Tools. It’s available from Melpa and GitHub.

My friend and erstwhile colleague Watts Martin has been seeking the one true path of light and virtue. After years of aborted attempts to embrace Emacs, he has, it seems, finally succeeded. Actually, snark aside, I understand his journey. It largely parallels mine.

Back when we were colleagues, I was still a Vim user but had already begun making feeble attempts to move to Emacs. It was always a silly thing, like the default scrolling behavior, that drove me away. In my case, it was finally moving to Lisp that pushed me over the edge to embracing Emacs. Martin’s journey was similar. He tried several times to move to Emacs but it just wouldn’t take, until it did.

While we Emacers can rejoice in another convert, Martin’s post is actually a balanced account of the strengths and weaknesses of Emacs. The downsides that Martin mentions are mostly the usual difficulties that n00bies encounter. Those of us who have made the journey from n00bie to journeyman can forget how hard it was at first. In particular, Martin calls out the difficulty of coercing Emacs into behaving as a “modern” editor by which he means using things like Tree-sitter and LSP. He complains, correctly, that there isn’t a good guide to help beginners configure Emacs to support a useful, modern workflow.

On the other hand, he notes that Emacs can molded into whatever you want it to be. It is, as I always say, a light weight Lisp Machine, although Martin doesn’t use that term. That fact, he says, makes it unlikely that folks who aren’t willing to “hack around with their editors” will ever adopt Emacs.

Martin ends by saying,

But the thing is, I think I also get Emacs. And once you get Emacs, there’s probably no going back.

I doubt he understands how true that is. He’s like a guy who’s fallen into quicksand and doesn’t realize it. For him, as for us, there is no escape.

In response to my post macOS Keybindings In Emacs, Paul R. Jorgensen notes that not every macOS Emacs port has the OS bindings defined. In particular, those ports based on the Mac’s Cocoa interface don’t support them.

Jorgensen has his own post on the matter that goes into a bit more detail. As far as I can tell, unless your using Mitsuharu Yamamoto’s Emacs port for the mac this isn’t a problem but if you’re not using a NextStep based port, you’re probably going to have a problem using macOS keybindings in Emacs.

Not to worry though. If you want those keybindings and your port doesn’t provide them, Jorgensen shows you how to get them. His setup assumes the ⌘ Cmd key is mapped to Super so that, for instance, ⌘ Cmd+s is mapped to Super+s. If you have ⌘ Cmd mapped to something else, it may not work as well. For example, if you map ⌘ Cmd to Meta the way many people do, then ⌘ Cmd+v is going to get you a scroll up rather than a paste.

As I said in my original post, I don’t think that there’s a lot a value in having these bindings added to Emacs—but see hmelman’s comment for an contrary viewpoint—so I wouldn’t bother changing my mappings if you’re a ⌘ Cmd == Meta user. Regardless, as Jorgensen says, “Emacs is a wonderfully flexible tool, is it not?”