Irreal

Extremeaxe5 has a question:

Hardcore emacs users, what rules do you use to separate what you do from within emacs / what you do outside of e https://t.co/TwgxVlW89k #Emacs

— Emacs BOT (@emacsbot) July 2, 2019

For me the answer is simple. If I can do it in Emacs, I do do it in Emacs. Actually, that’s not quite right. I suppose I could browse the Web from Emacs but that just doesn’t work well enough to make it worthwhile most of the time. Other than Web browsing I can’t think of anything that I could do in Emacs that I’m not doing in Emacs.

Mike Zamansky has his own answer: “If I can do it better in Emacs I use Emacs. Otherwise, I use Emacs.” Many other commenters agree.

The reasons for staying within Emacs as much as possible are well known and I’ve written about them before. The big ones for me are avoiding context switches and leveraging my Emacs muscle memory. Emacs über alles isn’t for everyone, of course, but has become a way of life for many of us. I’ve come to feel vaguely uncomfortable if I find myself entering text outside of Emacs.

If you’ve been paying attention to the Emacs scene, you may have heard about Polymode, a package that lets you have two or more active major modes associated with a buffer. The first question to occur to many is, “Why would I want that?”

Not to worry, the incomparable Mickey is here to explain it all. There are, it turns out, legitimate use cases for multiple major modes in a single buffer. I’m an old-timey, backend sort of guy so I’ve been spared having to deal with those use cases but for those not so fortunate, Polymode can be a real win.

The basic idea is that you want to deal with two (or more) different languages in the same buffer—Mickey uses the example of Python and SQL. The indentation and font-locking are, of course, different for the two languages and you’d like Emacs to do the right thing automatically. That’s what Polymode does. It detects where one language leaves off and another starts and adjusts the operative major mode accordingly. A configuration that handles a given set of languages is called a “polymode.”

The bad news is that although there are, apparently, a few polymodes already written, by and large you’re going to have to write your own for most things. The good news is that writing a new polymode is pretty simple and generally takes just a few lines. Mickey’s post shows how it’s done by creating a Python/SQL polymode. Doubtlessly, more prebuilt polymodes will start to appear once the package starts getting traction.

If the need for this or the ideas behind it are unclear to you, take a look at Mickey’s post. As usual, he does an excellent job of explaining everything. As a bonus, if you’re not British, you may, like me, learn a new word: bijou. How can you lose?

Yesterday, I wrote about abo-abo’s recent enhancements to the Ivy UI. After I wrote that post, I saw this tweet:

Yesterday I moved from my Ido & smex based workflow to ivy, sniper, and counsel. Transitioning was mostly smooth, and its definitely an improvement over my old workflow. #emacs

— Christian Herenz (@Knusper2000) June 29, 2019

I went through the same process almost exactly 3 years ago and have never looked back. Ivy and friends are so much better than the default mechanisms that I’m always a little surprised by tweets like the above because I always assume that everyone has abandoned smex and ido by now. Apparently not.

That brings me to the point of this post. If you haven’t yet tried Swiper/Ivy/Counsel you’re missing out and owe it to yourself to give them a trial. I can’t think of any reason at all to stay with smex and ido—although I’m sure some folks have special use cases or needs where they make sense—and even people using helm might want to try the Ivy suite out. Just the way swiper does implicit regular expressions makes it worth while all by itself but there’s lots more. Take a look at the manual if you want to see what it can do. Don’t be put off by all the functionality. It’s easy to get started by just using it as a drop in replacement for isearch and things like find-file. You’ll discover the other functionality as you go along. Give it a try; you will, I promise, be glad you did.

Abo-abo posts that he has made some usability enhancements in Ivy directory handling. If you’re like me, Ivy is a fundamental part of your workflow. As abo-abo says, the original idea was simple: provide a list of strings and a way of choosing one of those strings. Of course things quickly got more complex. One source of problems is dealing with directories.

The first example is dealing with file name completion. As you’re traversing down the path of directories, you need to select the proper one and move on to the next but you can’t just accept the directory because that would open the directory in dired instead of allowing you to choose the next directory in the path. Abo-abo solved that problem simply enough by using Ctrl+j to select that directory but keeping going.

The next problem is directory creation. That’s harder because Ivy couldn’t tell the difference between a new file and a new directory so he used a special key binding for that case. Recently he dug into the dired-create-directory and make-directory code and discovered that they pass Ivy a unique prompt that he could use to ascertain the user’s intention. Now it works the same as with files and there’s one less key sequence you have to remember.

He also fixed a long-standing annoyance involving the dired-dwim-target variable. You can read his post to see what the problem was and how he fixed it if you use that variable.

As we’ve come to expect from abo-abo, Ivy just keeps getting better and better. I can’t imagine how I got along without it. If you’re an Ivy user, be sure to read abo-abo’s post to see what’s new.