Irreal

One of the most useful capabilities I have on my computer is the ability to capture the URL of the current page in my browser. That doesn’t sound too exciting but I use it many times a day when I’m writing blogs posts or annotating code, or doing anything else where I want to reference a Web page.

This is particularly easy on macOS as I’ve previously recounted. Since then, I’ve tried to find ways of doing this in other OS environments. None of them are as easy as macOS but I’ve recently come across something that may solve the problem once and for all. That something is emacs-webdriver.

It’s a way of controlling your browser from Emacs which is what Applescript allows you to do on macOS. If you’re an Emacs user and often want to incorporate a URL from your browser this is a real boon. You can, of course, switch context to the browser, capture the current URL in the title bar, and switch back to Emacs but it’s a lot easier to simply invoke an Emacs command with a key shortcut.

Webdriver is a general API that’s not restricted to Emacs and can do much more than simply capture the current URL or title of the current Web page. Even if you don’t need all its capabilities, just being able to grab a URL from your browser is a useful capability. Again, I use this capability everyday in macOS and it’s something you may want to enable it on your own systems.

No, not electrocardiogram, Emacs Knowledge Graph. It’s a small project by Andrew Hyatt that is best thought of as light weight Zettelkasten sort of like the popular Emacs applications Org-roam and Denote.

Take a look at the GitHub README for an explanation of the project. There’s also a shorter description of the application on reddit but the best explanation is this video on ekg that demonstrates the app and discusses the design. The video is just short of 46 minutes so you’ll need to schedule some time.

One way of thinking about the project is that it’s Hyatt’s attempt to overcome the limitations imposed by Org’s “everything is text” principal. A practical consequence of this is that explicit forward and back links get replaced by tags. This makes linking notes essentially automatic: if two links share a tag, then they’re linked and discoverable from each other. To make this idea more useful, tags can be multiple words. Everything, even the note text, is stored in an sqlite database so searching is fast and effortless.

The project is still fairly new—although it is in Melpa—and Hyatt is still struggling with some of the concepts but he’s been using it at work for several months and hasn’t found any problems. All of this is explained in the video and if you have any interest at all in the package, you should spend the time to watch it.

This looks like an interesting project and it’s one I can see myself adopting. It seems like an excellent way to keep a set of notes: it’s easy to add notes and to find them later.

Over at Linux User Space, Leo and Dan have a short video giving a reasonably comprehensive history of Emacs:

Would you look at that! Another text editor #history hitting @tilvids today.

This time, it’s #Emacs.

Oh, you didn’t know #TECO preceded it? Well, you do now.https://t.co/Y5Qzpb6LX9

— Linux User Space (@LinuxUserSpace) February 16, 2023

They start with TECO and the infamous tower of Babel that grew out of every developer having their own set of macros leading Guy Steele and Richard Stallman to develop a standard set of Editing MACroS that everyone could use. From there, they trace Emacs’ development from a set of TECO macros to the current day GNU Emacs. Along the way, they discuss Gosling Emacs and its relation to GNU Emacs as well as the Lucid version that eventually became XEmacs.

The video is 14 and a half minutes long so it shouldn’t be too hard to fit in. If you’re freaked out by the warning about leaking your IP address in the Twitter link, just follow the above link and watch it on YouTube.

Vivek Haldar is a Python fan and considers Guido von Rossum “one of the best language designers of our time.” He was surprised, therefore, when von Rossum suggested in a Lex Fridman podcast that VS Code was the spiritual successor to Emacs. For many of us, that’s like lighting a stick of dynamite under our chair but Haldar considers the idea of VS Code being the spiritual successor to Emacs calmly and rationally.

Not surprisingly he disagrees. Von Rossum bases his assertion on the fact that VS Code and Emacs are both structured as an interpretive language engine at the core and the majority of the editor implemented in that language. In Emacs’ case, that language is Lisp. In VS Code’s case it’s JavaScript. Theoretically, that makes them both highly extensible but there’s a difference.

Haldar says that Emacs has two things that VS Code doesn’t:

Barrier-less extension

The idea that you can write some Elisp anywhere in Emacs, mark it, execute it with Meta+x eval-region, and have the effects take place immediately. If you like the changes you can add the code to your init.el and have its action take place every time you start Emacs.

Everything is a buffer

I’ve written about this before. As Haldar says, it basically means that whatever you do in Emacs, it’s in a buffer and subject to the usual Emacs editing and manipulation functionality.

I’d add a third Emacs advantage: Emacs is Free Software and not owned by anyone. I say that not as a true believing ideologue but as someone who’s been around long enough to know how Microsoft operates and to not trust them or their intentions. I worry that Microsoft will eventually revert to type and pull the rug out from under VS Code users.

In any event, Haldar reaches the same conclusion that I do: VS Code is not the spiritual successor the Emacs.

Yesterday I wrote about T V Raman’s post explaining how he uses the X Windows xcape command to provide extra keys and better ergonomics for Emacs. Raman has some nice ideas about improving the Emacs keyboard interface but they were, unfortunately, restricted to those using X Windows. That’s a lot of people, of course, but about a quarter of those who use Emacs are doing so on a Mac and Raman’s hack wasn’t available to them.

Jeremy Friesen to the rescue. Like me, he was intrigued by Raman’s post but unlike me he decided to do something about it. He had a head start because he’s a Karabiner-Elements user and Karabiner makes it easy to do the sort of thing described by Raman.

Take a look at Friesen’s post for the details. Not everyone will want to do this but if you think your workflow could benefit from overloading modifier keys to provide additional shortcuts and eliminate some chording, it’s nice to know it’s possible for Mac as well as X Windows users.

T V Raman has a post that may be interesting to those of you who run Emacs under X. That’s probably just about everybody who isn’t using a Mac so many of you may be interested. The TL;DR is that his method turns the modifier keys into what he calls buttons. For example, (with his setup) pressing (just) the Ctrl key will send Ctrl+e to Emacs.

His keyboard has three modifier keys on each side of Space and adding the two Shift keys gives him eight possible “buttons”.

The key to making this work is the xcape command in the Xorg keyboard configuration to define what each of the buttons produce. Raman links to his xcape and XModmap configurations so you can see how he set things up but you’ll probably prefer other mappings.

The advantage of Raman’s method is two fold:

1. It avoids chording for commonly use commands.
2. It gives you several (8 in Raman’s case) extra keys to do something useful with.

If you’re an X user and interested in improving your keyboard ergonomics or perhaps just gaining some useful shortcut keys, take a look at Raman’s post. If you’re not afraid of modifying your XModmap file it’s not hard to set up.

UPDATE [2023-02-17 Fri]: Added link to Raman’s post.