Irreal

If you write code, you’re probably always adding and deleting comments. It’s one of those things that’s so fundamental you’d think everyone already knows the best way of dealing with them but I often see questions about how best to handle them in Emacs. Mickey has a tweet with some useful tips on wrangling comments in Emacs:

`M-;’ inserts an inline, mode-appropriate comment in #emacs. With an active region it’ll (un)comment as needed.

`C-x C-;’ (un)comments out the line point is on.

`M-x comment-box’ draws a fancy box around a region.

The variable `comment-styles’ controls the formatting.

— Mickey Petersen (@mickeynp) February 11, 2022

Those commands are also useful as building blocks. For example, I like starting functions (especially in C) with a comment box that gives the name of the function and a short description of what it does but I like the boxes to extend to the end of the line. Here’s a simple function that does that:

(defun jcs-comment-box (b e)
  "Draw a box comment around the region but arrange for the region
to extend to at least the fill column. Place the point after the
comment box."
  (interactive "r")
  (let ((e (copy-marker e t)))
    (goto-char b)
    (end-of-line)
    (insert-char ?  (- fill-column (current-column)))
    (comment-box b e 1)
    (goto-char e)
    (set-marker e nil)))

Notice how it leverages comment-box to do the heavy lifting.

We all know that one of the chief—if not the chief—benefit of Emacs is its extensibility. We say it all the time. Irreal says it all the time. But every once in a while the truth of that statement comes crashing down on us in a particularly compelling way. Here’s a case in point:

I’m listening to a Visual Studio live video that was live 15h ago. There is a big deal of a new feature that was introduced: Save on window focus change
Here is the same feature for #emacs
(add-hook ‘focus-out-hook (lambda () (interactive) (save-some-buffers t))) pic.twitter.com/nW0ee0HA4c

— Emad Elsaid (@emad__elsaid) February 9, 2022

It can, I guess, seem like a cheap shot to make fun of another editor’s feature addition but the reality is that while the VSCode community was celebrating a brand new capability, Elmad Elsaid provided a one-line implementation of the same feature for Emacs that anyone could apply and enjoy right now without waiting for a new release.

All open source editors have this capability in some sense because, after all, you have the source and can make whatever changes you like but Emacs is running on Lisp so you can make changes without recompiling everything and the liberal use of hooks makes adding a feature like the one discussed here trivial.

With Emacs, there’s no begging the implementers for a change and waiting for the next version. Most of the time it’s a simple matter of writing just a bit of Elisp, adding it to your init.el, and enjoying your new powers.

I’ve said this several times but, really, MELPA is one of Emacs’ great resources. Think for a moment how important it is to your Emacs life and what you would do if it disappeared. How would you replace it? There’s ELPA, of course, but for ideological reasons it could never be as comprehensive as MELPA. There’s Nic Ferrier’s Marmalade Repo, which I thought was defunct but is rumored to be showing signs of life. Again, though, it’s restricted to Free packages so it, too, is unable to match MELPA’s coverage.

If all that seems too gloomy, don’t worry. MELPA isn’t going anywhere but has recently announced a way you can contribute to support its operations:

In the past we’ve gotten many requests about how people can help out the MELPA project. We now have an OpenCollective where you can donate.

Funds will go towards server costs and volunteer time.https://t.co/KOdzmqPynW

— MELPA (@melpa_emacs) February 7, 2022

If you want to contribute—and you should—go to the MELPA Open Collective site. Steve Purcell runs MELPA on a shoestring so you won’t be financing any Caribbean boondoggles. If each of us, who depend so much on MELPA, chips in a few dollars, Purcell can keep this vital resource running.

I’ve been using mu/mu4e for 5 years and love it. It really provides everything I want in a mail client except perhaps for handling HTML—which certain miscreants insist on sending to me—but even that’s an Emacs shortcoming that will undoubtedly be remedied in the future. When I first started using mu4e I thought I would have to install BBDB to help me map correspondents to their email addresses.

That turned out to be unnecessary: by default, mu4e uses the mailabbrev mechanism to complete mail addresses so it just sort of worked out of the box. As far as I can tell, this works by scanning stored emails to get possible completions. The problem is that old and erroneous addresses also come up so it’s sometimes hard to know which one is correct.

I just saw this reddit post by astoff1 that recommends using ecomplete for mail address completion. This has the advantage that the mail addresses are explicitly listed in a file (~/.mailrc) so there’s no ambiguity with old or broken addresses. The downside is that you need that file of addresses.

I’m going to do a bit more research to see if I can automagically generate at least a first pass at a .mailrc file. I’ve been content to let it just work for the last 5 years so I haven’t looked into how things actually work. Now, I may need to do that so that I can implement an ecomplete solution as astoff1 suggests.