Irreal

It’s astounding how many “standard” formats there are for date/time stamps. Two or three years ago, I gave up my American provincialism on the matter and settled on the formats

• 2018-05-09,
• 2018-05-09 Wed, and
• 2018-05-09 Wed 13:24.

I like them because they are unambiguous—unkike, say 10/11/12—and easy to parse programmatically. They also seem more logical because they move from the more general to the more specific. What kind of logical sense does “May 9, 2018” make?

Still, other folks prefer different formats such as ISO-8601, which I’d use except it confuses the civilians with the T and offset. Whatever your preferences, Grant Rettke has you covered with a hydra to generate timestamps in multiple formats. You may think it’s silly to have so many formats available but sometimes you’re dealing with entities that insist on a certain format and Rettke’s hydra let’s you use whatever’s appropriate. If your favorite format isn’t included, it’s trivial to add another.

Rettke leverages hydras for his workflow a lot and this is another excellent example of how their use can make your workflow easier. Some folks don’t like them but unless you fall into that category, you’ll probably find that they can ease your workflow by grouping similar tasks into a simple menu-driven interface.

Eli Zaretskii is asking the Emacs Devel list if there are any objections to releasing Emacs 26.1 in a week. That was on [2018-05-06 Sun] so we should be seeing the new Emacs soon. I’ve been running Emacs 26.1 RC1 for a while and haven’t had any problems. Some folks were pushing to get a couple more bug fixes in before the release but there doesn’t appear to be any show stoppers.

As always, congratulations to Eli, John, Nicolas, and the (many) others for their hard work. It’s really nice to have regular releases but it does mean a lot more work for the developers.

I almost missed this announcement but Sacha, as she often does, had me covered with her Emacs News list.

One of the questions that n00bs are always asking in Emacs venues is, “How can I get started with Emacs Lisp?” It’s a huge help if the requester has a little Lisp background, of course, but the real hurdle to my mind—others disagree—is learning the Elisp specific commands and idioms.

Chris Done has an excellent GitHub repository that contains an Elisp Guide. He assumes the reader has some programming experience but not necessarily that it’s Lisp experience. The guide covers many of the basic features of the language and is a good first look at Elisp programming. Done’s goal is to get the reader to the point that he can profitably read the manual.

If you’ve been wanting to try out Elisp or maybe just make a simple change to your configuration, this is a nice resource. As I say, it will get you to the point that you can fill in the blanks by reading the manual.

Marcin Borkowski (mbork) has a very handy tip for Counsel and Swiper users. The idea is that if you want to search for the symbol at point, you need only type Meta+n to use it for the search target. This works for Swiper and the counsel grep functions such as counsel-rg, counsel-ag, etc. See Borkowski’s post for the details.

As regular Irreal denizens know, I’m a huge fan of the Ivy/Counsel/Swiper suite and consider it one of my two most important packages (along with Org mode, of course). If you aren’t already using it, you should stop what you’re doing and install it right now.

If you’re not decided, Michael Hunsinger has an excellent introduction and tutorial. It by no means covers everything the suite can do but it does show the basic operations, complete with animated gifs. If you want to whole picture, take a look at the Ivy User Manual. It shows all the shortcuts and explains the wonderful regex interface. If you’re an Ivy user and not familiar the alternative regex modes, be sure to take a look at the Completion Styles section of the manual. With the later versions of the suite you can change the method on-the-fly so, for example, if you want to search for several terms in any order, it’s easy to do.

Take a look at Hunsinger’s post and see if you aren’t convinced. Really, it will make your workflow much more efficient.

Very few Emacs users—no matter how advanced—ever need to worry about the specifics of the Elisp bytecode, or even, for that matter, that it exists. Still, as guys like Chris Wellons have shown, it can sometimes be useful to have a basic understanding of the bytecodes.

R Bernstein has put together a comprehensive, book-length documentation on Elisp bytecodes. After a short introduction, the documentation considers the bytecode environment including the compiler, interpreter, and bytecode optimization. Then there’s a long section on the individual bytecode instructions.

Finally, there are sections on the changes in bytecodes between Emacs versions, a table of opcodes, and a reference section. There’s also a GitHub repository of the document source.

As I said, you probably will never need this but if you do, you’ll be very glad to have Bernstein’s documentation. It’s another example of the vibrant Emacs community.