Irreal

Over at the Emacs subreddit, InstinctsInFlow says that he’s a PhD student in computer engineering who has been using Emacs for a couple of years because of its support for VHDL coding. He really likes Emacs and want to find better ways of using it so he asked for advice on using Emacs as a PhD student.

I found the answers in the comments to be particularly useful. InstinctsInFlow does his coding in Python so he was particularly interested in how to use Emacs with Python in an optimal manner. Everyone has an opinion on this, it seems, but the suggestions were all good.

The other thing that almost everyone mentioned was, of course, Org mode. If you’re a PhD student, you’re going to be doing a lot of writing. Writing that’s apt to include a bunch of mathematics and there are really only two choices¹: Org mode or LaTeX. It’s certainly true that LaTeX gives you finer control but not much finer and in almost all cases Org is fine and it’s always easier.

There are some other good recommendations. If you’re interested in using Emacs for your PhD studies, take a look at the post. It’s short and has some good suggestions.

I’ve written many, many times about how Avy is one of my favorite packages. Probably 90 per cent of my Emacs navigation is done with Avy. As I’ve said before, you can think of Avy as a generalization Steve Yegge’s recommendation to use search for navigation. Yegge’s idea revolutionized the way I navigate around a buffer and Avy refines that idea and makes it even more useful. As I’ve also said before, if you aren’t using Avy, you’re working too hard.

Now Charles Choi has stepped up to make it even better with Casual Avy. Like his other Casual packages, Casual Avy provides a transient menu to the functions that Avy provides. That’s important because Avy provides too many of them to remember.

Until Casual Avy, most of us solved that problem by restricting our use to one or two of those functions. In my case that’s avy-goto-word-1 and avy-goto-char-timer. Some, like Karthik settle for just avy-goto-char-timer. After reading Karthik’s post I’ve been using avy-goto-char-timer more but I hardly ever use any of the Avy commands except those two.

In a sense, Casual Avy gives you the bet of both worlds. You can still use mainly one or two of the commands but have instant access to all of them at the cost of a single additional keystroke.

I’m really enjoying Choi’s Casual packages. They give you access to all sorts of arcane commands without having to remember a lot of little used keystroke shortcuts. Most of the time, you won’t need them and that’s the point: you don’t have to remember a lot of shortcuts but still have access to the commands you seldom use.

The “ATC” in the title is Air Traffic Control. You might wonder what Emacs has to do with air traffic control other than some engineer writing code for the system with Emacs. The truth is much stranger and surprising.

For a brief period of time, the Air Traffic Control system of the newly unified East and West Germany was running on Emacs. No, really. The German ATC system was running on an editor. The words don’t even seem to make sense.

I’ve heard this story before, but someone just posted a link to the story on the Emacs Wiki. As far as I can tell, I haven’t written about it before so I thought I’d share. The TL;DR is that after reunification, there was a huge project to combine the two countries’ ATC systems. An academic refugee from Symbolics was tasked to write the message router but didn’t know any languages other than Lisp. Being a “Herr Doktor” his word was unassailable but there was no Lisp on the system and no budget to buy one. There was, however, Emacs so Herr Doktor coded his message router in Elisp and for a little while airplanes over Germany were being controlled with the help of code running on Emacs. Proof that, as I always say, Emacs really is a Lisp Machine

It’s a truly amazing, not to say terrifying, story but the next time some VS Code partisan starts telling you how much better his editor is, ask him if it ever ran an ATC system.

Emacs Elements has a new video up. This one is about simplifying—perhaps “rationalizing” is a better word—the Emacs repeat commands. Those of you familiar with Vi(m) know that one of its nice features is a simple repeat command bound to the period key. Once it finds its way into your muscle memory, it’s surprising useful.

Sadly, Emacs’ repeat command(s) are a bit more difficult and not as useful. Still, they can be handy on occasion but, as Emacs Elements notes, they are bound to keys that can charitably be described as “arcane”.

One of the problems with Emacs repeat is that there’s not one but two commands: the simple repeat and the complex repeat. What distinguishes one from the other has always seemed a bit murky to me but Emacs Elements explains it well: if the command requires using the minibuffer, it’s a complex repeat. Otherwise it’s a simple repeat.

Emacs Elements rebinds the simple repeat command to Ctrl+., which is similar to Vim’s, and the complex repeat to Ctrl+z. Those bindings are simple to remember and make Emacs’ repeat commands worth getting used to.

I can see it being useful for repeating commands such as “delete 5 chars” when you want to delete a bunch a bunch of text but aren’t sure how many characters need to be deleted. Regardless, if you think you might find the repeat commands useful, it’s definitely worth your while to rebind them to something simple that doesn’t require multiple keystrokes.

The other day, I wrote about a way to put the time and date on the modeline when Emacs is in full screen mode. The reason I cared was because full screen mode hid all the date widgets and I had to move the cursor to the top or bottom of the screen to see the date. Or so I thought.

Summer Emacs responded that she also ran Emacs in full screen but the macOS menu bar—with the date/time widget—was displayed. After a bit of back and forth, Summer Emacs discovered what was going on. It turns out macOS has a setting that controls when and if the menu bar is displayed. The default, apparently, is to hide the menu bar only when an application is in full screen mode. You can change that to never hide it. I did that and now I can see the date in both Emacs and my browser.

Yes, that means that I have one less line of screen real estate but that’s a price I’m willing to pay. Now I can always see the date and time just by looking. I’m calling it a win.

I was going to let this play out in the comments. It is, after all, a niche issue and one restricted to Mac users. Still, most readers never see the comments unless they’re commenting themselves and I thought this was helpful enough to make sure that everyone who cared saw it.

Update [2024-05-25 Sat 17:21]: he → she (clarifying that Summer Emacs is a she, not a he).

Joe Marshall has an X little post on Lisp. I used X because I’m not sure of the correct adjective to use. Maybe “snarky”, maybe “cute”, maybe “enlightening”, maybe “interesting”. The idea of the post is that if you find yourself wanting some missing capability when writing in Lisp you can, in fact, simply add it. In other words, you can make Lisp into whatever language you need it do be.

Everybody knows that, of course, but it got me thinking that the same thing applies to Emacs. If it doesn’t do something you want or it doesn’t do it in the exact way that you want, it’s easy to make it do so.

Sure, you probably have to know Elisp to make a lot of the changes but despite what some folks tell you, it’s not that hard to learn Elisp. It’s mostly a matter of learning the API, not Lisp itself. Once you do learn it, you have an infinitely malleable editor at your disposal. Are there some upfront costs? Sure but they’re worth it and once you get past them you have an editor that can be made to do almost anything you can imagine.

Others have already embraced this possibility and now we can read and send email, listen to music, follow RSS, and a host of other things from within the comfort of Emacs. Just as Lisp is the programmable programming language, Emacs is the programmable editor.

I run Emacs and my browser in full screen and I spend almost all my screen time in those two applications. That presents a (very) small problem: If I want to know the date, I have move the cursor to the bottom or top of the screen to reveal one or another date widget. That’s not very handy and, even worse, involves using the mouse. It’s one of those tiny problems that I’ve learned to live with.

Until today. Bram, over at the Emacs Mastadon, showed us a bit of code that displays the time in the modeline if Emacs is in full screen mode. It uses display-time-mode to do this. I toggled it on to see what it looked like. It only showed the time but I was pretty sure I could make a quick hack to have it add the date.

Then I remembered that this was Emacs and someone else must surely have thought of that so I checked the documentation. Sure enough, if you set the variable display-time-day-and-date to t, it will also display the date. Now when I need to know the date, it’s right there on the modeline.

That doesn’t solve the problem when I’m in the browser. Sadly, there doesn’t appear to be a Safari widget that displays the date but I’m no worse off than I was before when I’m in Safari and the problem had disappeared when I’m in Emacs.

Chipping away at small problems, mostly by tweaking Emacs: it is, as I’ve written previously, like maintaining a Japanese garden. A work always in progress but never completed.