Note: this is a review of some of the more interesting features in this release. For a complete list of changes please be sure to read the UPDATING file.
This obviously isn't a feature, but I wanted to mention that I will be moving away from Mutt maintainership after this release. There isn't a transition plan, so I'll keep maintaining the 2.2.x series with bug fixes and security issues.
It's been my pleasure to keep the releases coming since version 1.5.24. Unfortunately the past year, my time and energy available has been decreasing. So my plan is to focus the time I do have on keeping Mutt stable, secure, and bug free; until someone else has the desire to head up (and support) new-feature releases. Thank you everyone!
Setting $sort to
"threads" enables threaded
viewing in the index. Previously, only
$sort_aux was used to affect sort order
between and within threads.
This release adds
$sort_thread_groups,
which controls top-level sorting between threads. For backward
compatibility, it defaults to
"aux", which delegates to
$sort_aux. However, it can be set to any value completely
separate from $sort_aux.
For example, to display the most recently active threads at the top of the index, while conversations within the thread (i.e. subthreads) remain sorted in normal order from top to bottom:
set sort = threads
set sort_thread_groups = reverse-last-date
set sort_aux = date
Note that both $sort_thread_groups and $sort_aux can use the "reverse-" and "last-" prefixes, and that their sort keys can be completely differently:
set sort = threads
set sort_thread_groups = reverse-subject
set sort_aux = last-date
However, using the "last-" prefix in both $sort_thread_groups and $sort_aux, with different sort keys can slow threading down. To handle that case, Mutt needs to perform two scans for the "last" value: one for each key.
This has been requested several times, and there was even a patch in the old Trac system for this feature. I resisted, but Vincent Lefèvre finally helped persuade me in ticket #362.
The patch allows the <Enter> and
<Return> keys to be bound
separately. It also creates a new key name
<KeypadEnter> reflecting the
enter key on the number keypad (this requires a version of
NCurses supporting the key). Perhaps more practically, this allows
ctrl-j
and ctrl-m to also be bound
separately.
See Enter versus Return in the
Changing the Default Key
Bindings section of the manual for details about the keys
and how they relate to the ctrl-j
and
ctrl-m keys in terminal
applications. If desired, also see the commits
f4ff768c and
4021ab59.
Due to a potential license conflict, I've added support for using
GNU SASL as Mutt's
SASL implementation library. This can be specified via the
--with-gsasl compile-time
configuration option.
There are very likely some bugs and issues to be ironed out, so please report issues you find.
For more details see Debian ticket 999672.
Some of the yes/no prompts in Mutt are controlled by quadoption or boolean configuration variables. While it's convenient to be able to change the prompt behavior (by turning it off, or by setting the default answer), it can be difficult sometimes to find the right configuration variable to set.
Starting this release, these prompts will have an additional "?"
listed. For example the prompt when exiting Mutt:
Typing "?" will display the configuration option used
to control the prompt:
By default,
using <skip-quoted> in the
pager (by default bound
to "S") will skip
directly to the top of the next unquoted part of the email.
This can be useful to quickly jump over a quoted section you've
read before, but can also be a bit disorienting without context.
$pager_skip_quoted_context sets the number of quoted lines to display above the unquoted section.
I was initially skeptical, but after trying it out I think it
greatly increases the usability of
<skip-quoted>. Please try it
out, and see what you think!
The $attach_save_charset_convert quadoption (defaulting
to
"ask-yes")
will convert a text-type attachment's character set when saving it
from the attachment menu.
If you've ever looked at the raw headers of an email and seen
text like
=?iso-8859-1?q?blah=20blah=20blah?=,
that is RFC2047 encoding. It is used to encode non-ascii text
in an email header, but has specific rules about where it can be
used.
One of the places it shouldn't be used is for attachment
names (usually stored
inside Content-Disposition:,
although historically it could be in other places.) RFC2231
encoding was created for that purpose.
Unfortunately, even though it's explicitly listed as prohibited by the RFC, a few mail clients still do so. You've seen this if you tried to save an attachment and saw a name like the one above.
Mutt has had $rfc2047_parameters for a long time to deal with the problem, but it was set off by default, because.... the behavior was prohibited. However, because the option name is fairly obsure, this often left users (even technically proficient ones) confused and blaming Mutt. So starting this release, I've turned it on by default.
I guess there may be a tiny chance someone wants to send an
attachment
named =?iso-8859-1?q?blah=20blah=20blah?=,
but I think that's much less likely than normal users
encountering the incorrect encoding.