Irreal

Florian Adamsky has a very nice post on handling acronyms in LaTeX
documents. Good style dictates that the first time you use an acronym,
you should provide the full written out definition. Later instances
can just use the acronym. That’s pretty easy to do with a small
document but for larger documents where there’s a lot of editing and
restructuring, the definition may get moved so that it comes after a
use of the acronym by itself.

Fortunately, there’s an excellent \(\mathrm{\LaTeX}\) package that
handles all this for you and Adamsky shows you how to use it. One
problem with the package from Adamsky’s point of view is that you have
to list the acronyms and their definition at the beginning of your
document. That makes it inconvenient to add a new acronym where you’re
in the middle of the document. To solve that problem, Adamsky wrote a
bit of Elisp that lets you add a new acronym on the fly without losing
your position in the text.

If you write in \(\mathrm{\LaTeX}\), you should check out the acronym
package. It probably won’t make a huge difference in your workflow but
will help remove one annoyance. You will probably also want to grab
Adamsky’s code so that you can add acronyms to the table as you need
them.

Eli Zarestskii has announced that barring any difficulties coming to
light, the Emacs 26.1 RC1 should be released next week. Zarestskii
expects that that will be followed in short order by the release of
Emacs 26.1 itself.

Relative newcomers to Emacs will see this as simply the usual yearly
release that has become standard for software in our industry. Those
of us who have been around a bit longer know that it wasn’t always
this way for Emacs. Major releases could be years apart and came when
they came. Thanks to recent maintainers—especially John and Eli—we now
have a more predictable (and frequent) release schedule.

It’s good to remember that this is a lot of hard work and it’s all
done by volunteers. Guys like John, Eli, and the other contributors
have families and real jobs that need attending to but still make time
to keep the Emacs project going and flourishing. We all owe them a lot
of thanks.

Grant Rettke has an interesting take on abo-abo’s Hydra package. His
idea is that you can use hydras for a sort of lightweight literate
programming. Most Irreal readers are already aware of hydras’ utility
as a way of gathering related functionality into a menu-driven set of
keystrokes with a common prefix. Hydra functions can be configured to
easily repeat with a single keystroke rather than the longer complete
sequence needed on the first call.

Rettke uses hydras for all that, of course, but he also uses them when
learning a new package or set of related functions. Check out his post
to see how he uses a hydra as a sort of notebook to record what
functionality is available and what keystroke to use to call it. It
is, he says, executable documentation.

Karl Voit captures my feelings about Emacs exactly:

Seeing #Emacs as an #editor is like seeing a car as a seating-accommodation.#PIM #orgmode #informationcentric #vim #editorwar #IDE #opensource

— Karl Voit (@n0v0id) March 4, 2018

I stumbled across the package Auto-YASnippet, by the prodigious
abo-abo, again the other day. I vaguely remember reading about it a
couple of years ago when it was first released. The idea is to create
a temporary yasnippet on the fly without leaving your current buffer.
That can be really useful when you want to create a series of nearly
identical entries in a program that differ only in a term or two.
Abo-abo describes it as a hybrid of keyboard macros and yasnippet.

You can do the same sort of thing with keyboard macros if you can
remember how to invoke the recursive editing features. Abo-abo’s
solution is much easier: you just write the body of your text, marking
the fields that will change by a ~. Then you can create as many
additional instances as you like, substituting different values for
the marked field(s). Take a look at the README for some examples of
how it works.

I’m not sure why this didn’t register with me more when I first saw
it. It’s probably because I don’t program in languages like Java or
JavaScript where a tool like Auto-YASnippet makes more sense and can
save some time. If you find yourself regularly writing nearly
identical definitions or other boiler plate, take a look at
Auto-YASnippet; it may save you some time.

Postscript: I had originally planned to publish this yesterday but
serendipitously Mike Zamansky scooped me by posting a video
demonstrating Auto-YASnippet in action. As I wrote then, that was
indeed fortunate because now you can see the package in action. If you
haven’t already, be sure to watch the video.

Mike Zamansky has another video up in his Using Emacs Series. This
time he discusses Artur Malabarba’s agressive-indent-mode and
abo-abo’s Auto YASnippet.

In what could be an example of great minds thinking alike but is more
likely simply a quotidian coincidence, I had planed on writing about
Auto-YASnippet today but I got scooped by Zamansky. Actually, that’s a
good thing because now you can see an example of them in action. I’ll
publish my post on Auto-YASnippet tomorrow.

Zamansky’s video is a couple of seconds over 9 minutes so you can
easily fit it in during a coffee break. As with all of his videos,
this one is well worth your time

My current workflow has two ways of grepping collections of files. For
grepping Git repositories, I use counsel-git-grep. It uses the fast
grep built into Git as a backend. For other collections, I use
counsel-ag, a recursive grep that uses The Silver Searcher for a
backend. I usually prefer to use counsel-git-grep because I can be
in any directory of the repository and still search everything; I
don’t have to worry about starting in the top directory.

Then I read this recent post from abo-abo. In it, abo-abo says that he
now uses counsel-rg, which uses ripgrep as a backend, for everything
because it is the fastest of the generally available greps. That
sounded pretty good but I was confused. As far as I could tell from
the documentation, ripgrep doesn’t treat Git repositories in a special
way. It will simply do a recursive search from the current directory
(or the one you explicitly specify, of course). So I queried abo-abo
about that and it turns out that counsel-rg (as well as
counsel-ag) now explicitly check for a Git repository and will start
from the repository’s top directory unless you specify some other
starting point.

What that means to me is that I don’t need the two ways of grepping. I
can simply use counsel-ag and it will do the right thing if I’m in a
Git repository. That leaves the question of whether I should
install ripgrep and use counsel-rg to do my greps. Ripgrep does
appear to be considerably faster than the other methods but unlike
abo-abo, I’m not dealing with 2G repositories and counsel-ag seems
more than fast enough. Still, it’s always nice to be faster so I installed
ripgrep so that I could try out counsel-rg anyway.

Be sure to read abo-abo’s post. It has some other information on his
workflow and handling such things as ignore files. You might also
enjoy this abo-abo post on ripgrep: he explains why he switched to it
and some of its advantages. And if you aren’t already using the
Ivy/Counsel/Swiper suite, stop what you’re doing and install them
right now. You will, I promise you, be glad you did.

Mike Zamansky has a new video up in his Using Emacs Series. After
commenting on what a great time it is to be an Emacs user, Zamansky
considers Autocomplete and Company mode. These, of course, are
completion packages for Emacs. They’re both “intelligent” in the sense
that they use individualized backends to be language aware.

Until recently, Zamansky was an Autocomplete user. He mostly used it
with the Jedi package for Python completion. This semester, though,
he’s teaching a C++ course and decided to try out Company mode because
it uses Clang (through Irony mode) to provide syntax aware completion
for the C, C++, and Objective C languages.

He’s just started his experimentation so the video represents his
preliminary findings. For me, though, the video reinforced a
long-standing prejudice against either one. I use the “dumb”
completion built into Emacs that basically looks at what’s in your
buffer and what you’ve typed recently to choose completion targets.
You have to explicitly invoke the completion so it never gets in the
way. Autocomplete and Company mode, on the other hand, are always
popping up buffers offering suggestions. I find that annoying and
distracting. Perhaps it’s because of my horrible experience with
Word-like word processors but whatever the cause I don’t want my
editor doing that. Some languages—I’m looking at you Java—can benefit
from auto-completion, I suppose, but I don’t use those languages so I
have no need to put up with its downsides.

Of course, not everyone is as curmudgeonly so it’s worth taking a look
at the video to see if one or the other works for you. The video is just
short of 18 and a half minutes so it should be easy to fit it in.