Irreal

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.

Emacs-Elements has a nice demonstration on using Emacs’ DocView to read PDF files. One of the nice things about DocView—as opposed to PDF Tools—is that it can read PS, DVI, Djvu, and ODF files as well as PDF files. The downside, of course, is the way it works. When you open a document with DocView, it uses an external tool to render it as one or more PNG files. That can take a few seconds for a long document but more importantly—for me, at least—is that the PNGs are cached. That makes it speedy to reopen the document but it clutters up your file system unless you manually delete the cache.

The video shows how to configure DocView and integrate it with Bookmarks+ to make it easy to locate and open documents. It turns out that you can use any of three external programs to render PDFs into PNGs and the video has some advice on which to use.

Most of the rest of the video demonstrates how to navigate through a document and do things like extracting a rectangular region. DocView is surprisingly featureful and you can see some of that in the video.

If you can’t get PDF Tools working or don’t want to bother trying, DocView is a builtin solution that works well. Its main deficiency, as compared to PDF Tools, is that you can’t annotate the PDF.