<<< Date Index >>>     <<< Thread Index >>>

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.