On Wed, May 24, 2006 at 04:11:18PM -0700, Gary Johnson wrote:
> Making mutt easier for newbies to use and to understand is a great
> idea, but changing variable and function names is not the way to do
> it. If you really want to help new users, add a section to the
> manual where variables are grouped functionally along the lines of
> your ideas for renaming them, and improve the rest of the manual by
> making the explanations more clear and with better cross-references.
This suggestion is right on the money, though I think doing it is a
little easier if all the variable names are themselves grouped in that
manner, if only because it makes them easier to track down and
organize for the person who is going to actually write the docs. But
even better yet, add a built-in configurator akin to what pine has.
For complex things like send-hooks (for example) this doesn't really
work so well; but for simple variables, it's much, much easier for the
user to check a box (which has reasonable on-line help) than it is to
read through the manual looking for the settings that one wants, and
edit a config file by hand to set all the settings manually. You
could do a dialog for things like send-hooks, though I'm not sure how
much value that really has...
I'm actually in favor of cleaning up the variable names for the sake
of consistency as well as aesthetics, but only as part of a major
release. But, I think if a well-designed configurator is included,
along with a conversion script for legacy mutt users, the names of the
variables changing is a moot point. The impact to users becomes
essentially zero.
I do agree 100% that it makes the code and documentation easier to
maintain, modify and use. And if it's done as part of a major release
(i.e. to Mutt 2.0) I think the argument of incompatibility is totally
lame and stupid. The point of upgrades is to make things better, and
that just about necessarily means that things will change in ways that
are incompatible. Users should expect that incompatibility is the
price of better software. Insisting that things remain compatible
stunts the growth of the project in the same way that MS-DOS (and
early versions of Windows) were stunted. It also makes the code
crufty as features and fixes are tacked on haphazzardly rather than
designed intelligently, again much like MS-DOS and Windows. And that
is the direction mutt is heading in. We're 4 years without a stable
MINOR release of Mutt, never mind a major one. That's pathetic.
Excellent recent contributions notwithstanding, I think for mutt to
continue to grow and be flexible, a re-write is needed. And I know
I'm not the only one who thinks that. These are the same forces at
work which led to the original discussion about forking MuttNG.
Admittedly, Thomas and others have been much better about adding
features that people want... But even still, in comparison to other
modern mailers, it seems to me that Mutt is starting to lose ground in
the "sucking less than others" category.
Some ways mutt is lacking:
- panes: the ability to manipulate (not just see) folder lists and
message lists while simultaneously reading messages
- built-in configuration tools: Mutt is a pain to configure, even
for seasoned mutt users. Built-in tools would aid greatly in
making mutt more user-friendly.
- multiple front ends: I rely heavily on Mutt's character-based
interface, and I'm happy it exists; but it still would be nice to
have a crisp, peppy GUI interface when I'm reading mail on my
local machine. With modular code and suitable abstraction design,
the interface calls could (potentially) actually not change in the
core of mutt's code, but only in initialization routines could
pointers be defined which point to the proper functions, thus
making this a lot easier to implement than it might sound.
- redesign of menus: some of mutt menus are cumbersome to use or
just plain ugly, especially for non-English translations (so I
understand). A new menu system which used panels to present
dialog boxes and pop-up menus would make mutt's character-based
interface cleaner and more friendly to use, especially for the
ever-growing universe of GUI-oriented users.
- creation of HTML mail: like it or not, HTML mail is popular.
While it has many detractors, it can't be denied that it provides
a way to write formatted e-mail which is very nearly universally
supported, and only possible in a rudimentary way using plain
text. Mutt should support creating HTML mail from user-generated
HTML files, and even support automatic text conversion (using
helper programs) to assemble multi-part messages.
- more efficient threaded design: a lot of "expensive" features that
people want (like accurate attachment counting or accurate display
of new/unread mail counts) which the current maintainers keep
dismissing on acount of performance impact would be much less of a
performance issue if mutt implemented them using threads. Message
counts and new mail detection could be done in the background
while mutt was otherwise doing nothing, waiting for user input.
These are just a few ways Mutt could suck less; it would be easy for
people to think of more features that could be added. Not everyone wants
these features, but a lot of people do, and probably a lot of people
who didn't want them would try them if they were available. By making
the code more modular, it should be easy to introduce such features
without bogging mutt down for users who don't want them. I think if
Mutt wants to continue to suck less than other mailers, this is the
direction it needs to start heading...
In the mean time, it would be really nice if we had a stable release
that included all the nice recent additions in functionality.
Oh and before someone says, "shut up and write the code..." as someone
inevitably will:
It's a big project. I couldn't possibly do it alone, even if I wanted
to. To be done right and well, it needs organization and planning: a
road map. And it needs a leader, which I am not. People don't like
me, which I don't particularly blame them for; I'm direct, I'm a
bitch, and I'm arrogant. Not a good combination for a leader. But
until it has a leader that people are willing to follow, and who has
some organization skills, the project I'm outlining doesn't have a
prayer of going anywhere. Mutt NG proved that, which is too bad,
because it was sorely needed then, and still is.
--
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:
pgp4t6PD9Giro.pgp
Description: PGP signature