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:
pgpu5gZakofeP.pgp
Description: PGP signature