Re: [Mutt] #1317: wish $edit_charset
- To: tony@xxxxxxxxxxxxxx, veronatif@xxxxxxx, dominique@xxxxxxxx, edmundo@xxxxxxxx, lhecking@xxxxxxx, pdmef@xxxxxxx, list2rado@xxxxxx, vincent@xxxxxxxxxx
- Subject: Re: [Mutt] #1317: wish $edit_charset
- From: Mutt <fleas@xxxxxxxx>
- Date: Fri, 03 Jul 2009 11:31:06 -0000
- Auto-submitted: auto-generated
- Cc: mutt-dev@xxxxxxxx, kurt@xxxxxxxxx, 239235@xxxxxxxxxxxxxxx
- In-reply-to: <065.916cf8507d439f9e2e301706b193529e@xxxxxxxx>
- List-post: <mailto:mutt-dev@mutt.org>
- List-unsubscribe: send mail to majordomo@mutt.org, body only "unsubscribe mutt-dev"
- Mail-followup-to: fleas@xxxxxxxx
- References: <065.916cf8507d439f9e2e301706b193529e@xxxxxxxx>
- Reply-to: fleas@xxxxxxxx
- Sender: owner-mutt-dev@xxxxxxxx
#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