What’s cooking in Sup next
The 0.7 release ain’t the only exciting Sup news. Here’s a list of interesting features that are currently cooking in Sup next, along with the associated branch name.
- zsh completion for sup commandline commands, thanks to Ingmar Vanhassel. (zsh-completion)
- Undo support for many commands, thanks to Mike Stipicevic. (undo-manager)
- You can now remove labels from multiple tagged threads, thanks to
Nicolas Pouillard, using the syntax
-label). (multi-remove-labels)
- Sup works on terminals with transparent backgrounds (and that’s fixed copy-and-paste for me too!), thanks to Mark Alexander. (default-colors)
- Pressing ‘b’ now lets you roll buffers both forward and backward, also thanks to Nicolas Pouillard. (roll-buffers)
- Duplicate messages (including messages you send to a mailing list, and then receive a copy of) should now have their labels merged, except for unread and inbox labels. So if you automatically label messages from mailing lists via the before-add-hook, that should work better for you now. (merge-labels)
- Saving message state is now backgrounded, so pressing ‘$’ after reading a big thread shouldn’t interfere with your life. It still blocks when closing a buffer, though, so I have to make that work. (background-save)
- Email canonicalization, also thanks to Nicolas Pouillard. The mapping between email addresses and names is no longer maintained across multiple emails. (dont-canonicalize-email-addresses)
The canonicalization one is a weird one. There’s been a long-standing problem in Sup where names associated with email addresses are saved and reused. Unfortunately many automated systems like JIRA, evite, blogger, etc. will send you email on behalf of someone else, using the same email address but different names. The issue was compounded because Sup decided that longer names should always replace shorter ones, so receiving some spam claiming to be from your address but with a random name would have all sorts of crazy effects.
Addresses are still stored in the index, both for search purposes, and for
thread-index-mode. (Otherwise thread-index-mode has to reread the headers
from the message source, which is slow.) Once thread-view-mode is opened, the
headers must be read from the source anyways, so the email address is updated
to the correct version.
So, incoming new email should be fine. Sup will store whatever name is in the headers, and won’t do any canonicalization.
For older email, you can update the index manually by viewing the message in
thread-view-mode, and forcing Sup to re-save it, e.g. by changing the labels
and then changing them back. Marking it as read, and then reading it, is an
easy way to accomplish this, at least for read messages.
You can also make judicious use of sup-sync to do this for all messages in
your index.
Discussion
To leave a new comment, enter your email address. A copy of the article will be sent to you via email.