Irreal

Mike Zamansky has published the latest video in his Learning Elisp series, Learning Elisp 8. It’s the second video about building a function to generate function header comments. This video continues the discussion of regular expressions by considering the rx macro and the related xr package.

The rx macro allows you to write a regular expression with a more functional notation. The xr package is the inverse of rx: it translates a regular expression in normal notation to the corresponding rx notation.

Some feel the rx notation is easier to use and understand than the traditional regular expression notation. In fact, Pay08 in the reddit discussion of Learning Elisp 7 complained that Zamansky didn’t mention rx, which he considers a must for dealing with regular expressions. I’ve never been able to warm up to using the rx macro and agree with Zamansky that it’s probably not worth learning because it applies only when writing Elisp and not to any of the other languages or utilities that have regular expressions. Zamansky suggests that the xr package may be useful for understanding regular expressions written in traditional notation but I don’t find the rx notation any easier to digest; your mileage may vary.

Finally, Zamansky considers the format function, which, as he says, is pretty much the same of C’s printf. With this video, Zamansky has discussed everything he needs to begin building his function header function.

The video is just short of 20 minutes so plan accordingly. It’s a nice introduction to the rx macro and related xr package so you should take a look at it if you aren’t already familiar with them. Don’t let my and Zamansky’s skepticism sway you; you may like them.

James Dyer has a quick tip that may be interest you. The issue is reverting buffers. There are several ways of doing this. One is to simply call find-alternate-file (Ctrl+x Ctrl+v). That’s what I always did but there’s the more specific revert-buffer (Super+u) that handles a few edge cases.

The problem with revert-buffer is that it asks for confirmation. If you’re calling it interactively you probably don’t want the confirmation. Dyer’s tip is to use revert-buffer-quick instead. It’s like revert-buffer but (usually) doesn’t ask for confirmation. Take a look at the online documentation to get the details.

Here’s another tip, this time from Irreal. If, like me, you usually call revert buffer for particular files or for a particular directory, you can set revert-without-query to inhibit the confirmation query for those files or directories.

In a sense, this is all small potatoes. Whether you need to confirm your intentions or not doesn’t matter much in the end but the thing about Emacs is that it does all it can to reduce friction in your workflow. It’s also a case study in why your mastery of Emacs is never complete. Both revert-buffer-quick and revert-wthout-query are obscure features that are hard to discover on your own but they’re there to help you even if they’re hard to find.

Isa Mert Gurbuz has an interesting post on some of the editing workflow he’s developed over the years for working with Emacs. The bulk of the post demonstrates some of the glue code he’s developed for working with various packages.

He starts with executing code in a buffer. You might want to execute the last s-expression, a defun that the cursor is in, a region, or even an entire buffer. You can do all that but each of them has a separate command. Gurbuz’s solution is to write a DWIM function that does the right thing depending on context. Nothing too unusual about that but he’s applied a bit of abstraction. The context remains the same for many languages other than Elisp but the particular functions vary. His idea is that his DWIM function doesn’t call any of these functions but returns a function that does. That way, he can supply the appropriate functions to call to his DWIM metafunction and get the actual function to call in return. He binds that directly to a key shortcuts so there’s no reason to even name the resulting function.

Next he considers eros as a way of showing an enhanced view of an expression, again in a DWIM way depending on context. He uses the same trick and metafunction as above to get a function appropriate to the language he’s using.

After that, he considers some functions from other languages like redshank from Common Lisp and clojure-thread-* from clojure-mode. Finally he considers various other supplementary functions and how he integrates them into his workflow to handle things like indentation and formatting. It’s a nice post with some good ideas. Definitely worth a few minutes to read.

Most every Magit user is, I’m sure, aware that the Magit menuing system has been refactored into a separate library, transient, that is available for anyone to use. I’m dimly aware that some Elisp projects—although I couldn’t name one off the top of my head—are already taking advantage of it. I just stumbled across a case of transient being leveraged in an individual user’s configuration.

Tory Anderson is using transient as a replacement for hydras. Emacs hydras are a package by abo-abo that provides a straightforward way to configure menuing systems in Elisp. They’re easy to set up with a simple description in your Elisp. You can take a look at Anderson’s post to see the code for one of his hydra replacements. I have a hydra that does essentially the same thing and the code looks almost identical.

To me, the interesting thing about Anderson’s post is not a particular hydra replacement nor the particular problem he’s solving but the idea of using transient instead of a hydra. I don’t see any advantage to using transient instead of a hydra and even Anderson says his efforts to replace hydras with transient are mainly a proof of concept. Still, it’s an interesting idea and shows how easy it is to take advantage of the transient library. Anderson has another post on transient and hydras if you’re interested in the idea. That post notes that the transient documentation is available in the Emacs help system as long as Magit is installed.

Mike Zamansky has posted the seventh episode of his Learning Elisp video series. In the last set of videos, he showed how to code a Rot13 function in Elisp. This video begins a new project: automatically producing function header comments. The idea is to parse a defun declaration and produce a comment listing the function name, its return value, and its parameters. After its generation, the cursor is left in a position for the programmer to provide more commentary on the various objects.

This video is an introduction to the problem and the main mechanism used to parse the function definition: regular expressions. The subject of regular expression is already difficult enough for most implementations such as the quasi-standard Perl regular expressions or even the Unix egrep regular expressions but Emacs regular expressions seem especially difficult.

The hardest part of Emacs regular expressions is understanding when and what special characters need to be escaped and even how many escape characters are needed. The problem is exacerbated because the rules are different if Emacs thinks it’s reading a string or a regular expression. Everyone hates them but despite several suggestions to improve them, they remain the same.

Zamansky spends most of this video explaining elementary Emacs regular expressions and how they can be used to identify complex patterns of text and perhaps replace them with something else. One example he shows is how to change a date in the mm/dd/yy or mm/dd/yyyy format to the dd-mm-yy or dd-mm-yyyy format.

It’s a nice introduction and makes the whole subject seem a little less intimidating. The video is a bit long—for Zamansky videos—at 29 minutes, 11 seconds so you’ll need to schedule time but it’s worth a look especially if you’re new to regular expressions.

I just stumbled across an Emacs Elements video from 9 months ago. It’s about the Emacs mark and how to use it. There are lots of videos about this and Irreal has commented on some of them but it’s one of those subjects that I, at least, have a hard time internalizing so it bears repeating for some of us.

One nice feature of the video is the use of visible-mark to display the placement of the two most recent marks. That helps a bit with the exposition.

The video starts with ways to set the mark and exchange it with the point. Most Emacsers know the basics of that but may not know that you can set an inactivated mark with Ctrl+Space Ctrl+Space. That’s useful if you want to set the mark but not specify a region.

Similary, Ctrl+x Ctrl+x activates the mark when it’s swapped with the point so the region between them is highlighted. If you don’t want that, simple specify Ctrl+u Ctrl+x Ctrl+x instead.

Next, the video considers ways to mark various objects: word, sentence, paragraph, buffer, function, s-expression, or page. These are useful for deleting, copying, or moving text.

Finally, the video considers ways of using the mark for navigation. You can set the mark at a particular location and return to it later by popping the mark with Ctrl+u Ctrl+Space. This is made more useful by the fact that Emacs sets the mark automatically for many large movement commands.

The video is 13 minutes, 26 seconds so you’ll need to schedule some time but not too much. If you’re like me and have a hard time internalizing these commands, it’s worth your time to watch it.