[In the style of Vincent Lefevre...] On Sun, Jul 05, 2009 at 01:49:22AM +0200, Vincent Lefevre wrote: > On 2009-07-02 14:19:29 -0500, Derek Martin wrote: > > 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. > > That's why one may need to switch between different locales (e.g. for > grep), because not all files use the same charset. Some files are > remote files, shared by several users, and one doesn't necessarily > has the choice. That comment is completely ridiculous. Use iconv to convert the file to UTF-8. If you need to, then make your changes, and convert it back. It's also completely ridiculous because if everyone used Unicode, instead of clinging to arbitrary obsolete encoding schemes, this problem would simply not exist. > > 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... > > If some users don't know how to configure their system, complain to > them, not here. Ridiculous. This is a discussion about whether Mutt should add a feature to allow users to circumvent problems caused by their stubborn desire to misconfigure their system, not about whether people do or do not do so. > I don't know what you mean here, but by default, Mutt does bad things > with charsets. The $thorough_search variable is broken by design and > should be removed. Completely ridiculous, because you didn't bother to explain what you meant by "does bad things." Also completely ridiculous because even if an application has a bug, it can and should be fixed; not blame the mechanism it tries to use for the fault. > > 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... > > This remark is ridiculous. This remark is completely ridiculous. > First because Mutt is one of the applications that break under a > UTF-8 locale (see above). Utterly ridiculous. Even if Mutt has some small number of minor bugs pertaining to character set handling, it can hardly be generally called broken under UTF-8. Also riducluous because it should have been clear from context that "broken" in this case meant "unusably broken" which Mutt clearly is not. > Then because one doesn't necessarily have the choice; even when > there are other similar applications that have no problems with > UTF-8, they may have more important bugs so that they can't be used. Completely ridiculous. You're describing a case where all the available choices are severely broken. In any case, you should complain to the vendor(s) to fix them, since they are unusable. > Anyway since Mutt allows the user to run it under non-UTF-8 locales, > using such locales should be assumed to be OK. Ridiculous. The context of this discussion is using one charset *while needing to use another which is not contained in the selected one.* Obviously other charsets can be chosen and used, but as stated several times already, that only makes sense if you only need to interact with that specific character set. Otherwise, you WILL at some point encounter problems. > > 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. > > Wrong. Completely ridiculous (and also very rude, but we expect that from you). > For instance, editors must respect the encoding of XML files > (which is provided with the file in some way), and doing something > else would be against the XML spec. This is unbelievably ridiculous. If a user wants to create an invalid XML file with an incorrect encoding, he should be able to. It may be the case that he wants to do so as an example of a bad XML file, or for whatever reason; but regardless his editor should not prevent him from doing so. But that's beside the point. Editors may or may not do this, but they must also be able to output the charset to the user's terminal. If they're using a strictly ISO-8859-1 terminal, for example, and the file they are editing contains Cyrillic characters, this will simply be impossible. But all editors must determine the locale that the user is using in order to display files properly to the user, regardless of what encoding the file is in or what encoding the editor uses internally. All non-broken editors do this, and do it by evaluating $LANG and friends. > Now more generally, emacs (and probably others) can be configured to > use an encoding declared by user to *match* the encoding of the file. > Saying that it is broken would be stupid. Ridiculous, like absolutely everything else you said, because it doesn't address my point at all. -- 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:
pgpSB7JOWE6mU.pgp
Description: PGP signature