[dropping from the bug report...] On Fri, Jul 03, 2009 at 01:30:36PM +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. > > 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. That's exactly what "deprecate" means though: "To express earnest disapproval of; to urge reasons against." So, you've deprecated it (you the developers, not necessarily you personally) without specifically conciously deciding to do so. But it's still deprecated... ;-) > The same counts for $charset, btw., which isn't deprecated either. It basically is though, and should be. Whenever someone asks about setting charset on mutt-users, those of us in the Mutt community who are well-versed in charset/encoding issues virtually always first mention that if you're setting charset manually, you're probably doing something wrong. I would daresay you're *definitely* doing something wrong, but it's occasionally useful, when someone really only needs western characters (like using translit). Though, I would still argue that they should just switch to Unicode and be done with it. The Mac is the only platform I've heard of still having Unicode-related issues (and shame on Apple for that), and AFAIK they can all be patched or worked around by now. > Feel free to comment on the added > http://dev.mutt.org/doc/manual.html#charset-handling part. It's a good start, but I think it could use some more details, like referring users to both of the man pages for locale (in section 1 and more importantly section 5). Personally I think it should also strongly encourage users to use Unicode, as it provides the cleanest possible method of handling multiple charsets. And, while it is not really related to Mutt per se, it may also be worth mentioning that some systems do not read the user's environment files until after their session is started, so if your system's locale doesn't match the user's locale, you likely will encounter problems. [I believe I encountered this on an image of Ubuntu Linux that was provided by my employer, which defaulted to en_US.] > > 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. Yes, that's what I'm saying. But also, editors which have their own charset handling (like emacs and vim) have mostly added that support years ago, because it was generally lacking in environments that needed it. > 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... ACK. Though, sometimes (even often) I think it's OK to say, "We have no desire to implement this, because of X, Y, and Z." And to be honest, I think that's better than just leaving it open indefinitely... Otherwise the reporter basically gets no feedback about how likely or when such a feature might be implemented. Leaving such items open may leave the requester with false hope that it will get implemented in a reasonable timeframe, and may also actually hinder the progress of Mutt. If you close it, and some people really do want it, someone else might implement it for you. > > 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. I don't think it is... I've long thought that Mutt needed a clean-up of it's configuration handling. But naturally, there would be endless arguemnt about that. ;-) FWIW, I think Mutt should have a configuration manager, and I think a lot of config options could be combined (like all the quad-options, for example) into one variable that governs them all (say, prompting_style for the example of the quad options, etc.). You would lose a little bit of flexibility, but you'd make the configuration much more managable. Anyway, I already know that idea would be very controvercial with the Mutt community, so I'll just stop there. ;-) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
Attachment:
pgpoziXbWeo8n.pgp
Description: PGP signature