line overrun in <sort-reverse> prompt
I've written a patch to implement index sorting by X-Label. I'll post it
momentarily in another message, but there's an issue I encountered with
it that's worth independent discussion.
The sticking point is that the sort prompt (the status-line prompt you
get when you press <sort-mailbox>) is getting very long. This patch
throws it over the 80-column mark, so regardless of whether this patch
is accepted, there's an issue next time something legitimate comes up.
Moreover, it's already over the 80-column boundary for <sort-reverse>.
This happened with the spam patch, and unfortunately I didn't notice it
when I developed the patch. I apologize for that. But because of that
oversight, it's now a standing issue in the CVS code base.
This patch suggests one approach to the problem, which is to change
- _("Rev-Sort
(d)ate/(f)rm/(r)ecv/(s)ubj/t(o)/(t)hread/(u)nsort/si(z)e/s(c)ore/s(p)am?: ") :
- _("Sort
(d)ate/(f)rm/(r)ecv/(s)ubj/t(o)/(t)hread/(u)nsort/si(z)e/s(c)ore/s(p)am?: "),
- _("dfrsotuzcp")))
to
+ _("Rev-Sort
Date/Frm/Recv/Subj/tO/Thread/Unsort/siZe/sCore/sPam/Label?: ") :
+ _("Sort
Date/Frm/Recv/Subj/tO/Thread/Unsort/siZe/sCore/sPam/Label?: "),
+ _("dfrsotuzcpl")))
That is, rather than "(k)ey", it presents "Key" with the keystroke
capitalized. This has some drawbacks, particularly that it's
non-intuitive. I keep wanting to press the capitals, and so does at
least one of my testers. I chose not to make it case-insensitive because
it's a translated string, and perhaps it's appropriate to use capitals
in some translations. But that just amplifies the problem with this
solution.
I'm not sure what else to suggest, really. Three ideas come to mind,
though there are problems with all of them:
1) Adapt the sort prompt to present only the most common sort keys,
but allow keystrokes for any of the available sort keys. For
example, if we can judge that people rarely want to sort by
recipient or to un-sort, then (r)ecv and (u)nsort could be
removed from the prompt text:
_("Rev-Sort (d)ate/(f)rm/s)ubj/t(o)/(t)hread/si(z)e/s(c)ore/s(p)am?: ") :
_("Sort (d)ate/(f)rm/(s)ubj/t(o)/(t)hread/si(z)e/s(c)ore/s(p)am?: "),
_("dfrsotuzcp")))
Note that the third parameter still has their keystrokes, so (r)
and (u) still work -- they're just not presented.
2) Same as #1, but somehow prioritize the keys so that as many
as will fit in your terminal width are shown. Nice from the
usability perspective, but more annoying to code.
3) Develop a sort menu, where sort and sort_aux can both be selected
from a list. Much more work, but has the advantage that it would
be more flexible if the sort options are extended some time. I
recall that Daniel Eisenbud once considered adding a tertiary
sort key, but concluded that it wasn't needed at the time.
I'm sure there are other reasonable solutions available, but these are
what I've thought of in the last few days. Primarily I'm just trying
to address the existing problem with the line overrun on rev-sort, and
also to provide a little room for future functionality, whether it's
from second- or third-party patchers or from the main mutt code tree.
xlabel_sort will survive either way, but since I'll need to address this
problem in it, I'd like to do it in a way that other developers can
appreciate.
So, any comments?
--
-D. "Neque porro quisquam est qui dolorem
dgc@xxxxxxxxxxxx ipsum quia dolor sit amet, consectetur,
NSIT->ENSS adipisci velit."
"Quia dolor sit." -- Cicero, De Finibus Bonorum et Malorum.