Irreal

Emacs Elements has been vlogging up a storm lately and has another useful video on Emacs line commands. The video covers four Emacs commands that all deal with removing lines from a buffer. The four commands that the video considers are:

1. flush-lines
2. kill-matching-lines
3. keep-lines
4. copy-matching-lines

The first two commands, flush-lines and kill-matchinfg-lines, both remove lines that match a regular expression. The difference is that flush-lines deletes the lines without adding them to the kill ring, whereas kill-matching-lines does the same thing but also adds the deleted lines to the kill ring.

The situation is similar with keep-lines and copy-matching-lines. The keep-lines command deletes all lines that don’t match the regular expression, while the copy-matching-lines command simply copies the lines that match to the kill ring but doesn’t delete anything.

There are several subtleties involved with the use of these commands. For example, in the absence of a region, they work like search in that they work from the point to the end of the buffer but anything before the point is unaffected. There are also rules about what the region must cover and casefolding so be sure to watch the video for the details.

It’s a nice video that explains some really useful commands. It’s only 5 minutes, 34 seconds long so it should be easy to fit in.

Emacs Elements has another interesting video up. This time it’s about some useful selection commands from from Xah Lee. The first of these is a command to select the current line. I use Steve Purcell’s whole-line-or-region for this and it’s by far my most used selection command. Lee’s version is similar but has the advantage that you can reinvoke it to select subsequent lines. It’s hard to overstate how useful a command of this sort can be. It doesn’t seem like it would be but once you start using it, you’ll never want to be without it.

The second command selects a paragraph or block. It’s almost exactly like mark-parapgraph (bound to Meta+h) except that it also selects the line following the block instead of the line preceding it. It works the same as org-mark-element (also bound to Meta+h) when invoked on a block.

The final command, xah-extend-selection, is very much like Magnar Sveen’s expand-region. It starts by selecting the current syntactic unit and expands the selected region with each subsequent invocation.

Whether you use Lee’s versions or one of the alternatives, these are all very useful commands and well worth integrating into your workflow.

Unduly-noted is a new Emacs user but that didn’t stop him from figuring out how to leverage Emacs to streamline his workflow. The TL;DR is that he wanted to import lectures and ancillary data from a course he was taking into Emacs. The lectures and extra data were in separate directories on the course Website and were not named in a way that facilitated sorting them in his Dired listing.

His first solution was to import and rename them manually with a numerical prefix to indicate the lecture number but that was labor intensive and tedious so he moved to using keyboard macros for the renaming but he still needed to manually change the numerical prefix. His final solution was to put the numerical prefix in a register, insert the value into the new name, and then increment the register value. It’s a nice solution that makes accomplishing his task much easier.

Somehow, long ago, I got it into my head that using a register in a keyboard macro required a special keyboard macro command. Unduly-noted’s post makes it clear that that’s not true. You simply use registers the same way you would if you weren’t in a macro:

1. Set the initial value before starting the macro.
2. Insert the value of the register in the appropriate place.
3. Increment the value in the macro.

It’s a nice post that demonstrates how to combine keyboard macros and registers to solve a simple problem. As usual, knowing just a little bit about Emacs makes it easy to automate repetitive and mundane tasks.

A couple of months ago, I wrote about Charles Choi’s post on Emacs defaults. Choi had a list of defaults with which he disagreed. I agreed with him on some of list and disagreed on other parts. It was, though, an interesting post and I even learned something. Now Sandra Snan over at Idiomdrottning has her own list.

Mostly, it’s hard to argue with her about the list or her suggested replacements. The only exception is one that I doubt any Emacs user would agree with: Ctrl+h, she says, should be a backspace instead of an entry to the Help system. Yes, her rationale makes sense. It is, after all, the ASCII character for backspace but No True Scotsman Emacser is going to agree with her on this one.

The rest of her list makes sense to me. She considers:

• Placing of backup and autosave files in the current directory.
• Copying a backup file rather than moving it.
• Spaces ending a sentence.
• Indentation using TABs and spaces.
• Requiring a final newline in a file.
• frame-inhibit-implied-resize.
• Showing trailing whitespace.
• Killing the whole line.

As I said, most of these seem non-controversial to me except spaces ending a sentence. The proper number of spaces after a period ending a sentence is a battle that rages within and without the Emacs community. Irreal has plowed that ground many times so I won’t belabor it here.

Take a look at Snan’s list and see what you think. Perhaps you’ll decide to change some of the defaults on your own system. Regardless, Emacs, as always, lets you have it your way.

If you’re interested in editors or even just Emacs internals you probably know about gap buffers. They’re a way of holding the data being edited so that it can be updated and displayed quickly and easily. It’s not the only method and certainly not the most obvious. The first thing most of us think of is an array of lines but gap buffers has substantial advantages over that.

The short story about gap buffers is that empty space is opened at the point so that text can be added, deleted, or edited. When the point is moved to another region, the old gap is closed and reopened at the new location. Newer editors mostly use more modern data structures for this such as piece tables or ropes.

Troy Hinckley has been experimenting with replacing the Emacs C core with Rust. Recently, he started looking at the best way to represent a text buffer. Rust, he says, has some particularly good implementations of ropes but he wondered whether they really were better than gap buffers for this particular application. He decided to answer the question scientifically.

He wrote an instrumented version of gap buffers and some of the Rust rope implementations and
ran some benchmarks. The results were illuminating. Gap buffers performed much better than you might expect against ropes. His post takes a detailed look at the question so you should definitely head on over there if you have any interest at all in the matter. It’s a good post and an excellent example of letting the evidence decide an issue.

The first official edition of the ELPA and Emacs Zine has been published. This edition is more concerned with Emacs than ELPA but it’s promising to be a useful resource for Emacs users. The current episode considers the discussion of clojure-ts-mode, the passing of Thien-Thi Nguyen, adding the compat library to Emacs core, package-vc, adding peg.el to core, some contributions to Eglot and Tree Sitter, and a discussion of perl-mode.

There’s also a discussion of Tree-Sitter and a list of new packages. The zine is looking for contributors so if you’re interested in making your voice heard, this is your opportunity.

This zine is a welcome addition to our community. You can think of it as an adjunct to Sacha’s Emacs News but with an emphasis on ELPA. In any event, it’s worth taking a look at.

This is a sort of advertisement for EmacsConf 2023. Sacha Chua has published a list of talks and it looks like it’s going to be a really great conference. The list is really useful. It’s not just roster of the talks and who is giving them; each entry includes a summary of the talk and a bit about the speaker.

If you follow Chua, you know that she’s done a lot this year to automate the management of the process. You can check her site for the posts describing what she’s done. She’s also giving a talk about the new processes she’s developed.

I’ve read through the list and looked at the description of the talks that seemed interesting to me and, as I said, the conference looks as if it’s going to be a win. If you’re like me, not every talk will be interesting to you but there are plenty, in various categories that will be. Even my interests, which are probably a bit eclectic, are well represented and I’m pretty sure that will be true for almost all Irreal readers.

One of the things I’ve learned from following Chua’s work this year is how much work she and the other volunteers do. That—and simply the love of automating things—is undoubtedly why she took to time to computerize as much of the process as possible. If you’d like to chip in, they’re always looking for volunteers. If you can’t help out, be sure to drop by in December to watch the talks that interest you and join in the discussions afterward. The conference will be online again this year so it should be relatively easy to attend.

Emacs Elements has a really excellent video on features, requires, and autoloads. The putative subject is speeding up the Emacs load process and perhaps even Emacs itself. The idea is that if, like me and Emacs Elements, you have a lot of specialized functions in your init.el or .emacs, you can extract them out to separate files that you can byte compile and perhaps set to autoload.

The autoloading will speed up your Emacs load time, of course, but even when you must require the file, byte compiling it will make Emacs run faster. The video explains how to set all this up. It turns out to be simple to configure and maintain.

The first step is to run emacs-init-time to find out how long Emacs is taking to load. That may or may not be useful. For example, my configuration involves decrypting and loading my authinfo file so my load time includes waiting for me to react to the password prompt and the time it takes me to enter it. You can solve this by loading Emacs twice in a row but regardless, if you think Emacs should show a bit more alacrity during loading, this video shows you some easy ways of accomplishing that.

Any reasonably experienced Emacs user knows about require and autoload and perhaps even feature but the details of how, exactly, they work may be a little murky. This video clears that up and shows you how to leverage them to speed up your Emacs load and running time.

Charles Choi offers a small tip that many of you might find useful. Choi spends a lot of time in online conferences and chats. These often involve interlocutors in other time zones and, of course, it’s useful to know what time it is in those time zones. For those of you who, like Choi and I, live in Emacs, there is the world-clock command that list the times in various time zones. You can open it another a buffer beside of below your chat buffer and stay on top what time it is for everybody you’re talking with.

The problem is that it’s a bit limited. Here’s the default output:

Seattle   Friday 06 October 15:30 PDT
New York  Friday 06 October 18:30 EDT
London    Friday 06 October 23:30 BST
Paris     Saturday 07 October 00:30 CEST
Bangalore Saturday 07 October 04:00 IST
Tokyo     Saturday 07 October 07:30 JST

That’s great but what if you’re talking to someone in Denver or Beijing? You can’t expect the command to list every possible place where you might be talking to someone, of course, but if you regularly chat with someone in Beijing, it would be nice to have it listed. This is Emacs so of course you can do that. It turns out that there’s an alist of TIMEZONE/PLACE that you can edit to customize the output to your liking.

Again, this is a small thing but it’s a nice amenity and, in the way of Emacs, you can configure it to meet your specific needs.