Irreal

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.

Sven Seebeck has taken inspiration from Charles Choi and implemented a transient to ease one of his frequent operations. That task was playing music with EMMS. His needs, he says, are pretty vanilla. He typically just wants to play an album or perhaps a specific track from an album. He’s not concerned with playlists.

He cleverly let Dired do most of the heavy lifting. by opening a Dired buffer to his music repository, he get a listing of the albums and by selecting an album, the songs in it. The rest is pretty simple as you can see by looking at his code. It’s very easy to follow and understand.

The point here is not to highlight yet another transient menu: they’re simple enough that anyone can write one simply by following, say, Seebeck’s example. Rather, the point is, once, again, how the flexibility of Emacs allows you to do this sort of thing quickly and easily.

A very short quickie today.

The ever prolific Nicolas Rougier has another nice snippet for us. It’s a way of enclosing some text in a box. It’s a tiny bit of code but it can produce some very nice output. Take a look at the example at the end of his gist.

It’s another nice example of how flexible Emacs is and how it lets you adapt it to whatever you need it do be.

CleanPrinciple5, over at the Emacs subreddit, asks an interesting question. He wonders why texinfo isn’t more popular. If you are and always have been an Emacs user, you might find that a reasonable question. On the other hand, if you ever tried to use Info without Emacs the question is apt to elicit a, “Well duh!”

Here’s my answer to CleanPrinciple5’s question: The Info utility is basically unusable. In the old days, most of the (useful) GNU documentation was available only in Info format so I was forced to use a TCL application to read it. It was still horrible but at least it was usable. All that got better when I started using Emacs; its Info interface at least makes sense.

The Unix tradition is to use man pages for a summary of how to use a program and, when necessary, a longer document—in PDF these days—to describe details not appropriate for a man page. For example, the yacc man page described the command line options and some other details but the description of how to use it to generate parsers was left to a separate paper, typically in the documents directory or the printed manual. GNU combined those two approaches into texinfo documents.

It seemed like a win and would have been except for the brain dead Info reader. Even after moving to Emacs, Info documents still leave a bad taste in my mouth and I avoid them when I can. I’m sure many other users feel the same.

Still, they’re better than simple PDF documents because they’re indexed and hyperlinked and most of them have a section with the same information traditionally contained in the Man pages. All the information you need in a single document that should be easy to read but isn’t because the readers are terrible.

Update [2024-05-19 Sun 12:37]:
Techinfo → Texinfo. Also better distinguished between Info documents and the Texinfo language.

Álvaro Ramírez has a really handy tip for renaming files under version control with wdired. If you don’t already know about wdired, stop whatever you’re doing and find out about it right now. It’s really magical. The TL;DR is that you can set a dired buffer to be editable and any changes you make—typically to the file names—will be reflected in the actual files. Mickey, over at Mastering Emacs, has a nice introduction.

Ramírez really likes being able to change file names with wdired but was unhappy that those changes weren’t reflected in git in a convenient way. Naturally he set out to remedy the situation. As he discovered, he needn’t have bothered. Wdired already has that handled: you just need to set dired-vc-rename-file non nil. Once you do that, git will show the files as renamed and ask you to commit the changes.

On the one hand, this is a small thing but Emacs, of course, makes it easy to do the right thing so even if your files are under version control—not just git—you can rename them and be sure that dired will inform your version control system of the changes. It makes wdired seem even more magical.