Irreal

Protesilaos Stavrou has posted another of his excellent videos on Emacs. This time it’s about the Emacs Diary and Calendar operations and how they work together. It turns out that the diary and the calendar are tightly integrated and work together to provide a particularly nice workflow.

If you use the diary feature, you should definitely watch Stavrou’s video. There are lots of features involving the calendar that you may not know about. The same advice applies if you’re looking for a simple reminder list. Even though Stavrou doesn’t use the diary as a diary, his video shows you how to use it that way too.

As Stavrou notes, you can do all this in Org mode as I and many others do. Stavrou, though, wants a simple system to remind him of upcoming tasks and doesn’t need or want the extra functionality that Org offers for this particular job.

As usual, Stavrou has tweaked things to better fit his needs. For example, he’s added a bit of Elisp to to send him an email every morning with the day’s events. He also configured the diary is give him a warning \(X\) minutes before an event.

He’s built a nice system that works well for him and probably others but I’m already doing all this in Org-mode and don’t intend to change. If I were just starting, though I would give it some serious thought. Likewise, if I ever decide to keep a diary—in the sense of today’s thoughts and observations—I’d almost certainly use the diary for that.

If you’re like me, you probably don’t think very much about activating and deactivating the mark. We know it gets set when we do a large movement or when we set it manually with Ctrl+Space. We know that the current region is defined by the point and mark and maybe even that we can jump to a whole list of current and previous marks.

Leave it to Marcin Borkowski (mbork), who’s an expert at teasing out Emacs minutia, to discover and explain some of the mystery surrounding the deactivation of the mark. It turns out that there’s both a function and variable named deactive-mark. The function does just what it says on the tin: if you call it, the mark is deactivated.

The use of the variable is a little more complicated. The TL;DR is that Emacs has its own notions about when to deactivate the mark and that this is mediated through the deactivate-mark variable. Being Emacs, a user can, of course, change Emacs’ default ideas of mark deactivation. You can read all the details in mbork’s post.

The truth is that you’ll probably never need to fine tune Emacs’ mark activation/deactivation but if you’re writing a function that depends on the current mark being maintained, you should definitely take a look at mbork’s posts to learn how to avoid having Emacs change it out from under you.

Update [2021-04-14 Wed 18:04]: Added link to mbork’s post.

As a nice coda to Saturday’s post on native compilation, the incomparable Mickey has his own post on native compilation. As most Emacers know, Mickey is an Emacs expert and his opinions on Emacs matters are always worth paying attention to.

Mickey says that native compilation is a significant step forward that has few downsides. Those “downsides” boil down to a new dependency (libgccjit) and the fact that initial compilation is slow. He adds that even the slow compilation has improved in the last 6 months.

He ends the post with his recipe for compiling the native compilation branch. With the coming merging of that branch into Master, it will be marginally easier. Of course, the feature is still under development so it’s not for the timid but if you don’t mind living on the edge or if you want to compile a second version of Emacs to play around with, it’s pretty easy.

Eli Zaretskii has announced that he expects to merge the new native compilation code into the Master branch next week. This is a significant milestone for a really important feature.

Most of the comments were along the lines of “I’ve been using this feature for months and haven’t had any problems.” A few expressed concerns about some edge cases but I didn’t see any show stoppers. The largest TODO appears to be documentation.

Once it gets merged into Master, we can reasonably expect that it will officially be released with Emacs 28. Perhaps—we can only hope—native compilation will put an end to the “Emacs is slow” snark. But probably not.

Over at Emacs Redux, Bozhidar Batsov has a short post on using Meta+! to run a shell command from the minibuffer. The output can go to various places—see Batsov’s post for the details—but usually what you want is to specify the prefix argument (Ctrl+u Meta+!) so that the output of the command is inserted at point.

It’s a useful command but I hardly ever use it. I’m much more likely to use shell-command-on-region (Meta+|) which pipes the contents of the buffer into a shell command. Analogously to Meta+!, specifying the universal argument will cause the contents of the buffer to replaced by the output of the shell command.

Emacs has so much builtin functionality that you probably won’t use these commands very often but sometimes they’re just what you need.