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

UI stuff (was Re: How to display format=flowed?)



Incidentally, one of the reasons I'm in favor of improving the
modularity of mutt's code is so that other UIs can easily be designed
for it.  I agree with another poster that it is useful to have an
index which is > 80 columns, but I still want my e-mail windows to be
80 columns wide.  I haven't thought much about what form this would
take; but that's largely because with the existing UI it's impossible,
and coding a new one would involve a complete re-write of mutt, such
that it would no longer be mutt.  FWIW, I think the power and
flexibility of mutt remain unsurpassed.  However, I often find a
variety of aspects concerning the user interface to be sub-optimal and
even outright undesirable; in some ways I think the UI is still in the
dark ages.  As Thomas has just admitted, he is rather stubborn (though
not any more stubborn than I, myself =8^) ), and seems much more
concerned about making mutt behave the way he thinks is right, rather
than giving users what they want.  [I don't really mean this to be the
complaint/insult which it may sound like... in a lot of ways,
Thomas's stubbornness has benefitted Mutt greatly.]  Modularizing the
code would allow people to develop patches that are much easier to
integrate into Mutt, probably requiring much less maintenance even if
they are rejected.  Thus it would give people the opportunity to
improve mutt in many ways, without the current level of pain of having
to maintain such patches should Thomas remain steadfast in his
stubbornness.

I suppose this point (the format=flowed issue) is one such way, though
it is a relatively minor problem.  The biggest drawback to Mutt's UI,
IMO, is the inability to continue to see the message index while
composing a message.  At work, much of my workflow is e-mail driven,
so if I need to write a somewhat lengthy e-mail, I sometimes will run
two copies of mutt in different xterms, so that I will not miss
important e-mail.  This also is a way to maintain an index of a
different width than you are reading e-mail in, albeit not a very
optimal one (because you must navigate mail folders in two different
windows).

I guess I think that mutt ought to have the ability to run in two or
three different windows simultaneously (folder view, index view,
message view).  Each of these views could independently be enabled or
disabled, allowing people to continue to use Mutt just as it is now.
This sort of UI  would allow a user to use an xterm of say 100
columns, using all of those 100 columns for the index, while splitting
the bottom into 2 panes where the message is displayed in 80 columns,
and the folders and message counts are displayed in the remaining 20
characters (all of this configurable, of course).  When a user edits a
message using a text-based editor, mutt would run their editor in the
message pane.  That shouldn't affect users who want to use gnuclient
or some external GUI editor to edit their messages...

This can be done with curses in one xterm, much as emacs or vim can
do; it doesn't necessarily require a GUI Mutt interface, or some
elaborate scheme to make mutt run in two xterms (though I think that
both of those would be kind of cool, personally).  I know there are
people who agree with me, and I suspect there are quite a fair number
of them.  But the current code and development model for mutt don't
really seem to allow for this; and I suspect Thomas will remain
stubbornly against that idea.  Greatly improved code modularity
reduces the pain of maintaining patches that Thomas rejects, which
thus reduces the barriers to people hacking on Mutt.  And of course,
all the traditional benefits of code modularity (maintainability,
easier debugging, etc.) still would apply as well.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

Attachment: pgprv4KHi1wW6.pgp
Description: PGP signature