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