Irreal

I’ve been happily using Interleave to takes notes while reading PDFs ever since I read about it in Piotr Limanowski’s excellent post on Reading for Programmers. It’s a great way to take notes that are synchronized with the PDF.

Gonçalo Santos has produced a similar system, org-noter, that provides much of the same functionality as well as some others. I temporarily loaded it so I could try it out. One thing from the documentation that I liked about it was that it can remember your place in the PDF so that it’s easy to take up where you left off. With Interleave, I do that by making a temporary note that I delete when I continue reading. Sadly, I couldn’t get that feature of note-taker to work. I’m probably doing something wrong but it’s not obvious what.

Other than a couple of minor items in the way it handles the notes buffer, it operates pretty much like Interleave. There are not enough differences to get me to switch but if you haven’t loaded either yet, it’s worthwhile trying them both out.

If you’ve used org-noter and have thoughts on it, please leave a comment and enlighten us all.

Ruben Berenguel has a useful post on Emacs tweaks from other editors. Berenguel works at a company where virtually everyone uses a different editor and even though he’s an Emacs user, he gets to see useful features from the competition.

Berenguel decided to to try to recreate some of those features in Emacs. He begins with Magnar Sveen’s excellent multiple cursors, which many, or perhaps most, of us already use. He then moves on to a few other packages that recreate features from those other editors that make the editing experience easier.

You may or may not want to use any of Berenguel’s tweaks but it’s certainly worthwhile taking a look to see if they’re something that could improve your workflow.

Bill Ward has a handy post on how to manage and create Gists with Emacs. It mostly involves installing gist.el and its dependencies. After the installation, you can easily edit existing Gists or create a new one.

If you publish code or other snippets as Gists, this may be a timesaver for you. It’s a short post so there’s no reason not to give it a read.

I, and many others, have written thousands of words about the advantages of using Emacs for blogging. In my case, I could, if I wanted, publish Irreal and virtually never visit the site itself; I can do everything from Emacs. I’ve been blogging at the two incarnations of Irreal for 9 years and would have quit long ago if Emacs didn’t make it so easy and enjoyable.

But today, I want to turn that on its head and say a few words about how blogging has helped me become a more effective Emacs user. It’s not just typing over 600,000 words into Emacs—although that helps, of course. It’s more about what I’ve learned regarding Emacs from blogging.

The first, and most valuable, benefit is what I learn from my readers. Sometimes it’s a matter of asking a question and getting informed answers. More often, though, I write about some aspect of Emacs use and readers help me flesh out my understanding by providing new details and interpretations that I hadn’t considered.

The second advantage is that because I spend a lot of time working on the blog, I’m always looking for and implementing micro-optimization’s to make it easier. Once I’ve written some Elisp to make blogging easier, it’s available for use in other tasks too.

An example of this is the jcs-insert-url function that I wrote about last week. I originally wrote the function to make some blogging task a bit easier but now I use it all the time for adding Web links to emails and other documents. This is typical. Almost everything I do to make blogging easier ends up helping ease other tasks as well.

So the takeaway is that if you want to get better at Emacs, using it for blogging is an excellent way. It’s certainly worked for me.

In yesterday’s post, I wrote that I had installed the new version of mu/mu4e but that the inbox and searches were showing some deleted messages as well as the ones I was looking for. I was gearing up to dive into the code when I noticed that the “extra” messages appeared to be from the same threads as the unread ones. Once I realized that, it was easy to figure out what was going on. A little RTFM brought me to §7.4.3 of the user manual where I learned about the option mu4e-headers-include-related that controls whether related messages (those from the same thread) are also shown. Apparently the default value was changed from nil to t in version 1.0.

I can see where that might be a useful default for some workflows but it’s a disaster for mine. After a bit of thought, I realized that that’s because I get three types of email messages:

1. Those from the clueful who use the interleaved posting style;
2. Those from the non-clueful who reply at the top and let their MUA add the original email at the bottom;
3. Emails from mailing lists.

The first two types always provide any missing context so I don’t need to worry about threads and I always the delete the third after reading them—they’re in the list archives if I need them—so most of the thread comprises deleted emails. That’s why I was seeing a bunch of deleted emails in my inbox. They were from the thread of the current email from a mailing list.

Now that I know the option exists, I can see where I might occasionally find it useful. Happily, the developers have me covered. All I need do is type W in the headers view to toggle it on or off.

One final note: if you like the option and leave it on you should use ] and [ to move to the next and previous unread message rather than n and p. There’s all sorts of useful keybindings for the headers view that you’ve probably forgotten about since you first skimmed the manual. It’s worth taking another look at them.

So the TL;DR is that the “problem” was indeed as configuration issue and after the appropriate adjustment I’m back to enjoying mu4e just as I always have.

Good news for all you mu/mu4e users:

The mu/mu4e e-mail searcher and mail client have reached 1.0 — after 10 years! Rejoice — https://t.co/U5zyjtVRwI pic.twitter.com/SpehjHyfxp

— djcb (@djcb) February 3, 2018

I’ve really been looking forward to the “format equals flow” support in the mail reader so of course I downloaded and installed it right away. If you’re a Mac user, the 1.0 version has not yet reached the Homebrew distribution but if you’re compiling it yourself, it’s just a matter of the usual configure, make, sudo make install dance. It worked without problem for me on macOS and will, I’m sure, be just as easy on Linux. Once you’ve installed the new software, be sure to do a

mu index --rebuild

to update your index.

Except for one problem, everything is working flawlessly. The problem is that when I open the inbox or even search for, say, new and unread messages, I get several already deleted messages listed as well. If I do the search manually with

mu find flag:new flag:unread

I get the correct messages listed.

I’m guessing that this is some problem with my configuration because I don’t see how even a minimal check—let alone the three 1.0 alpha releases that the developers made—could miss something like this. I haven’t had any time to devote to tracking down the problem yet so I don’t know what’s going on. If you’re seeing the same thing, please leave a comment so that I don’t waste time bebugging my configuration and so I can let the developers know.