Irreal

Just a quick tip from Ruslan Bekenev: find-grep-dired. It’s a nice way of running grep directly from a Dired buffer. The nice thing, as Bekenev points out is that the result is a filtered Dired listing of all the files that contain the specified regular expression. That means that you can do any of the standard Dired operations on them.

The command is really easy to use. The starting directory is already filled in for you, although you can edit it if desired. Then you just specify the regular expression and Emacs takes care of the rest.

You should contrast this with the Dired dired-do-find-regexp command (A) that searches only the marked files and produces a standard grep output. The commands are different but both can be useful. They’re just another set of tools in your Emacs arsenal.

Mike Zamansky has returned from his European vacation and is jumping right back into his Learning Elisp video series. The current video is the start of a new project: automatically inserting an Emolji into an Emacs buffer.

This video is an easy introduction to the project. The idea is that the text :bird:, say, should be replaced by 🐦, the Emolji of that name. That’s not too hard. Zamansky starts with a short list of Emoljis and names arranged in an association list. The rest is easy. Simply look up the name in the association list and substitute the corresponding Emolji.

The first video is concerned with implementing a simple function to do this. Right now, you have to call the function manually to do the substitution but Zamansky plans to make this automatic by invoking a hook function. After that, he is going to use overlays to to display the Emolji but keep the underlying text the same. Finally, the plan is a capture all this in a minor mode.

You may or may not be interested in having this capability but that’s not the point. The point is to demonstrate how to do things like automating actions with hook functions, use overlays, and even implement a minor mode.

The video is 15 minutes, 32 seconds long so you’ll probably have to set aside some time but, as always, Zamansky’s videos are worth the time. If you already know some Elisp or have watched the previous Learning Elisp videos, you probably won’t learn much new from this one but it’s setting the stage for the more advanced techniques that are coming.

Eli writes to tell us that the Emacs 29.1.90, a pretest for Emacs 29.2, is available. It seems like 29.1 was just released and we’re already in the early stages of the Emacs 29.2 release. The point releases are mainly bug and bolt tightening fixes, of course, but they’re still a welcome addition to the Emacs family.

As always, thanks to Eli and all the other developers who have worked so hard on this new release. If you can, please help out the effort by using and testing the pretest. It will help the developers clean up any remaining problems.

One of the first things every writer learns—probably in high school—is to avoid using the same word repeatedly in close proximity to each other. I’m really strict about that to the point where I try to avoid using the same word close together even twice. For me at least, it’s hard to get this right the first time. When I first read a post right after reading it, there’s almost always some repeats that I have to fix up.

Marcin Borkowski has the same problem. Borkowski’s problem is even greater since he’s often writing in English, which is not his first language. To help with that problem he wrote a bit of code to find out how far away from a given word other instances of that word are. In addition, he highlights those words giving him a nice visual image of how close the collisions are.

The code is reasonably short so you can just suck it into your own init.el if you’re interested in a tool like this. A year and a half ago, I wrote about Albert Heinle who had a similar problem and also made his code available.

Other editors may or may not have a function to help with discovering repeated words but how many can let you add that functionality to the editor on your own? Even if an editor claims to be “extensible” how many have an extension language powerful enough to do the job easily? This is Irreal so you all know the answer.

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.