On Thu, Jul 02, 2009 at 12:39:10PM +0200, Rocco Rutte wrote:
> Mutt has $config_charset which, for the same reason, should be
> deprecated if I follow your argumentation because setting UTF-8
> everywhere would make it'd be superflous.
The $config_charset variable already is deprecated! From the manual:
Recoding should be avoided as it may render unconvertable
characters as question marks which can lead to undesired side
effects.
Exactly. Any time you are trying to deal with a different encoding
from the one your system is configured to use, you're asking for
trouble. A tremendous amount of e-mail appears on mutt-users and
mutt-dev exactly because of this problem. The overwhelming majority
of that e-mail would disappear if people would just stop trying to do
things that are inherently broken...
Also, this option was added at a time when it made more sense; it was
added in 2003 or before, IIRC, and at the time dealing with different
encodings was painful, and getting UTF-8 working on all but the latest
bleeding edge distros was also painful. It is, IMNSHO, obsolete.
Don't get me wrong -- I believe in supporting legacy code whenver it's
reasonable to do so... I'll be one of the first to complain when
something breaks legacy code. But you shouldn't necessarily try to
bridge the gap between the legacy and the modern. With regards to
character sets, Mutt already does support the legacy. However, it
mostly does not, and SHOULD not, try to mash the legacy together with
the modern. That's what this suggestion attempts to do. I think it's
a crazy bad idea.
If you need to deal with multiple character sets, the ONLY SANE
SOLUTION is to use Unicode uniformly. You might be able to get a lot
of what you want done other ways, but you're going to keep butting
your head against places where you can't, and you're going to have to
do a lot of hackery along the way in order to get done just the bits
that you can do. That is a circumstance that should be actively
discouraged by software developers everywhere, as it makes more
headaches than it solves.
Now, if a user stubbornly insists on using some legacy application
that really does actually break under a UTF-8 locale (this should be
pretty rare by now), that is and should be regarded as the user's
problem... not one for Mutt devs to solve or work around. Unicode is
the right solution... it's the ONLY solution that works in all
cases. If your particular app doesn't work under Unicode then there's
almost certainly a substitute that does. And even if not, if it isn't
connected directly to e-mail, then it's not Mutt's concern. And even
if it is directly connected to e-mail, it's still not Mutt's concern,
since thousands of e-mail users use Mutt without whatever it might
be...
> I'm not sure we can and should generalize that all editors involved
> really derive their encoding from $LC_ALL and friends, especially using
> GUI editors.
I think you have to assume exactly that: All of the "normal" editors
DO derive their encoding from $LANG... all the major vi clones, emacs
and xemacs, jed, joe, pico, all the usual CDE-, KDE- and Gnome-shipped
editors. Any editor which does not is *broken*, and Mutt should not
concern itself with supporting that.
This is not to say that Mutt should never interoperate with broken
software; but IMO the only time Mutt's maintainers should spend time
on it is in order to make it work with e-mail programs that are
liberal with their interpretation of Internet e-mail standards, i.e.
other MUAs or the various MTAs and MDAs. If a user wants to use a
broken editor, or similar supporting software with Mutt, and it
doesn't work, that's their problem. There are lots of alternatives
that are not broken. You guys have way too much else to do, without
worrying about trying to hack mutt to work with broken supporting
userware.
One other concern I have, as a long-time Mutt user and supporter, and
occasional contributor, is the complexity of Mutt, especially
configuring Mutt. There are already *WAY* too many variables, and
more are added on a fairly regular basis. Users can't figure out how
to do what they want to do, because they can't find it in the manual.
Asking them to read the manual has become somewhat of a joke, because
it's almost 150 pages. For an e-mail client? That's crazy...
--
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 due to spam prevention. Sorry for the inconvenience.
Attachment:
pgpMaI8aoxVzQ.pgp
Description: PGP signature