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

Re: [Mutt] #1317: wish $edit_charset



Hi,

* Derek Martin wrote:
> 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.

Well, that's not the level of deprecation as for things like $wrap, or
$edit_hdrs. $config_charset isn't deprecated. This is rather a warning
that its use should be avoided because if you don't exactly what you're
doing you end up with random things being broken. The same counts for
$charset, btw., which isn't deprecated either. Feel free to comment on
the added http://dev.mutt.org/doc/manual.html#charset-handling part.

> 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...

ACK.

> 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.

Maybe. As editors mostly roll out their own charset handling, and
keeping in mind that the report is from 2001 (!), it may not be
necessary anymore to add $edit_charset. Also, nobody ever asked for it
again, nor does the reporter.

Many wishlist items we have in trac are not the ones where a significant
number of people really badly miss a feature, but are those were
somebody has an idea that likely only he really cares about. Some don't
even really care but say "hey, I have this idea, how about implementing
it?". I'm sometimes tempted to close some wishlist items *I* think are
pointless but I don't dare to just close them...

> 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...

It's really large, yes, but that comparison is a bit unfair. Mutt is not
for everybody and thus has lots of knobs for people who need to deal
with large amounts of e-mail which means reduced time per mail. I only
care about some of them which other find superflous and vice versa. Once
you've added them it's hard to drop them. :(

Take mime_lookup, for example. For an explanation of it to make sense to
a potentially new user, you need some words about MIME types (format,
major types, etc.), that MIME parts even exist and that they carry a
Content-Type to eventually explain that mutt can map insufficiently
labeled attachments to a saner MIME type. Oh, and since mime.types is
used, you have to explain the format, search locations, etc, too.

When you drop mime_lookup and implicitely do all that as likely many
other (GUI) mailers do, you can explain filetype-based viewer selection
in one sentence, not several pages.

When you have a built-in editor like Apple Mail.app has, and you
silently default to format=flowed for everything, there's no to explain
it and its caveats. For mutt, we have to explain things because given
its nature, for supporting creation of f=f messages, it can't support it
completely on its own.

Rocco

Attachment: pgprKoeZ6Uowf.pgp
Description: PGP signature