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

Re: [Mutt] #1317: wish $edit_charset



#1317: wish $edit_charset
------------------------------------------------+---------------------------
  Reporter:  Tony Leneis <tony@xxxxxxxxxxxxxx>  |       Owner:  mutt-dev
      Type:  enhancement                        |      Status:  new     
  Priority:  minor                              |   Milestone:          
 Component:  charset                            |     Version:  1.4i    
Resolution:                                     |    Keywords:          
------------------------------------------------+---------------------------

Comment(by Derek Martin):

 {{{
 On Thu, Jul 02, 2009 at 12:39:10PM +0200, Rocco Rutte wrote:

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

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/1317#comment:>
Mutt <http://www.mutt.org/>
The Mutt mail user agent