Irreal

Years ago, Albert Heinle was writing his thesis. A common error that many or most writers must deal with is using the same word repeatedly in close proximity. I certainly do and so did Heinle. He was using Emacs and LaTeX to write his thesis and he looked around for some software to automatically check for a repeated word within a given radius. He couldn’t find one but he was using Emacs so he wrote his own.

Heinle recently came across his word repetition code and decided to make it available to anyone who needs it. He says he used the project to learn Elisp so the code should be considered beta quality. He’s promised to work on it and it is, in any event, a single file so it should be easy to adapt it for your own uses.

When I’m writing an Irreal post, I generally go over it several times editing as I go. Just before I publish it I make one more pass. The most common problem I find is reusing the same word within two or three sentences.

If you write prose and find yourself repeating words too often, try out Heinle’s repetition detector. Perhaps it will help.

Andrea over at Where parallels cross has decided to post some shorter tips in addition to the blog’s longer offerings. The first is some Elisp to count the number of tags in your agenda files. When I looked at the code, I thought it was a bit too complicated for what it was trying to do.

My first objection was the onetime use of the macro but it turned out that Andrea already had it so that wasn’t a problem. The real issue is that the code duplicated a lot of already existing functionality. I remembered writing a post a couple of years ago where I needed to list all my agenda tags. It turned out that org-global-tags-completion-table did just that. It also eliminates duplicates and nil entries. In fact, if you look at the code, it does pretty much what Andrea did.

Here, then, is my rendition of counting Org tags:

(require 'dash)

(->> (org-global-tags-completion-table)
     -flatten
     length)

715

One final note. The tags for each file begins with a property string such as

#("JOURNAL" 0 7
 (inherited t))

so you should really subtract the number of agenda files to get an exact count.

Philip Kaludercic has an interesting post on the new Emacs 28 context menu feature. It has some useful information on how to use and configure the feature. The TL;DR is that you can configure menus to be context sensitive. For example, if the point is on a file path, the menu can add an entry to open that file. Kaludercic gives several other examples and provides some demonstration code to show how the capability can be used.

Emacs 28 will soon be with be officially upon us—the first pretest has already been released—so it’s worth taking a look at Kaludercic’s post if you have any interest in this sort of functionality.

But my interest in his post really concerns a meta-issue that he raises: that of using a mouse and menus with Emacs. As I said just the other day, I’m content to let people find the workflow—Emacs-based or not—that works best for them. That includes using a mouse and/or menus with Emacs. Kaludercic feels the same—sort of—but is suspicious of those of us who avoid using the mouse and menus.

Contra Kaludercic, I’m don’t have a fear, irrational or otherwise, of the mouse and use it all the time in, say, the browser or others apps where it makes sense. But the thing is, in my estimation, it doesn’t make sense in Emacs. I don’t care what Kaludercic and Rob Pike say, I’m faster and more efficient in Emacs without the mouse. The same goes for menus. I always have them enabled because it’s hard to do otherwise in macOS but the only time I ever invoke them is for seldom used commands that I can’t remember and know is on a currently available menu. That happens no more than once every couple months at most.

Again, do whatever works best for you but grant leave to those of us who have other workflows to do the same.

Just a quickie today. Bill over at ATMakers has a short video on Why He Uses Emacs. It’s actually a nice example of using keyboard macros to convert raw data into the required form.

I like it because it’s a realistic example. Very often when we want to convert a data set to some other format, we have the problem that the source data is not completely regular. Theoretically, this means we can’t write a quick and easy macro to do the conversion but, of course, that is not how we work. If there are one or two outliers in the data, we just convert everything according to the canonical data and fix up the outliers by hand afterwards.

That’s exactly what Bill does in his video. Most of the data is converted perfectly but the two outliers are easy to fix by hand and the entire process is much more efficient than converting each datum by hand or writing an app that does the right thing for each entry. Instead of an hour or two of tedious work or programming, Bill converts the first entry while recording his keystrokes and then applies that to all the other entries. The fact that it doesn’t work on a couple of irregular entries doesn’t matter; they are easily fixed by hand.

The video is only 6 minutes, 15 seconds long so it should be easy to find time for it.