<<< 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 Rocco Rutte):

 {{{
 Hi,

 * Derek Martin wrote:




 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.


 ACK.


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


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

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