Irreal

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.

Timothy Unkert is an Emacs user but prefers to use Markdown over Org-mode. He’s posted a video that describes using Markdown in Emacs. I’m very much a “different strokes for different folks” type of guy as the Hippies used to say so I’m perfectly happy for people to use whatever software works best for them. That said, after watching the video I’m at a loss as to why anyone would prefer to write in Markdown. Sure, sometimes you need to write in Markdown for various reasons but to prefer it? Karl Voit has explained at length why Org-mode markup is the best of class.

The first issue is inserting links. Unlike Org-mode the link isn’t displayed nicely as a link but instead shows the hard to read markup. Worse, Markdown-mode allows you to enter only a single word for the link description. I almost always want more than a single word (as the two links in this post show) so that’s deal breaker for me. Unkert fixes it by editing the actual link markup but that’s lame. I suspect that the real problem here may be configuration issue on Unkert’s machine or at worst an artifact of the Emacs Markdown implementation.

The issue with link display carries over to other text styling. If you want to italicize a word or phrase, you surround it with a single stars but the result is just the word or phrase surrounded by stars unlike Org that will actually produce italics.

Watch the video. Almost every aspect that Unkert demonstrates suffers in comparison to Org-mode. In one sense, this is unfair to Markdown because these problems are specific to the Emacs implementation but if you’re an Emacs user I can’t see any reason, other things being equal, to prefer Markdown to Org-mode.

Nacho Barrientos has an interesting video in which he explains how to run an eshell process in the background. Barrientos illustrates this with the sleep command. Normally, if you enter

sleep 4

in Eshell, Emacs will hang until sleep completes in 4 seconds. Barrientos’ idea is to use the Emacs compile mechanism to run the command in the background. The output is redirected to the *compile* buffer and the Eshell prompt returns immediately.

That’s a nice way of starting a long running process from Eshell and being able to continue working in Emacs. He also has a way of burying the *compile* buffer and getting a message when the process completes.

There’s not a lot of code needed to implement this. You can see the relevant function in Barrientos’ init.el. If you use Eshell regularly and sometimes want to invoke long-running processes, it’s worth taking a look at this video. The run time is only 4 minutes, 21 seconds so it should be easy to fit it in

UPDATE [2021-12-31 Fri 13:03]: In the comments, Niklas Eklund writes that he has a package that does the same sort of thing. You can read his post about it here. Elkund’s package works with any shell so it may be a worthwhile addition to your configuration.