Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 11:20:21PM +0200, Richard Atterer wrote: While we're at it: How on earth can I get rid of those Warning: locale not supported by Xlib, locale set to C messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts etc in mutt. Unfortunately, this produces the above error message with lots of X programs - especially annoying when you use at(1); you always get a mail with the error message. I got an error very similar to this. possibly that error, though not only for mutt. Basically it was for any X program pretty much. Back when I had an X installation I had compiled myself (4.0.2) on potato. I had compiled form the instructions with the X source, and got that error with all programs, it was not till I read the DRI compile howto page a few months later and saw this instruction in http://dri.sourceforge.net/doc/DRIcompile.html === 9.3 Update Locale Information To update your X locale information do the following: cd ~/DRI-CVS/build/xc/nls ../config/util/xmkmf -a make make install === once I did that it all worked fine and I have not seen the message since. See You Steve -- [EMAIL PROTECTED] http://wibble.net/~sjh/ Look Up In The Sky Is it a bird? No Is it a plane? No Is it a small blue banana? YES
Re: Bug#95975: mutt: doesn't use charset anymore
On Sat, 5 May 2001 10:57:43 -0700, Ben Gertzfield wrote: Just use LC_CTYPE=de_DE. It'll work fine in mutt. (The problem is, if I remember correctly, that X uses ISO8859-1, without the first dash.) Ok, but now I am confused... LC_CTYPE=de_DE LANG=de_DE LC_MESSAGES=C Should give me german umlauts and the prompts/messages should still be like before, right? Do I really not have to set ISO-8859-1 somewhere? Alexander -- Hackers confuse Xmas (25 Dec) with Halloween (31 Oct) Alexander Koch - - WWJD - aka Efraim - PGP 0xE7694969 - KOCH1-RIPE
Re: Bug#95975: mutt: doesn't use charset anymore
Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve However, Steve $ LANG=hr_HR LC_COLLATE=C ls -A Steve .A .B .C .a .b .c A B C a b c Steve which was Arthur's point, I believe. That means you can't have ls sort in a different order though (as defined by native language) without messing up the hidden files. IMHO, it seems that ls should (perhaps with a special option which can be aliased to be the default) treat files with a leading . as special, and put these before the other files. After all, the leading . is not defined by the language being used, rather it is a hack used by many user level programs that consider the file a hidden file. (sorry if I missed the point of all of this) -- Brian May [EMAIL PROTECTED]
Re: Bug#95975: mutt: doesn't use charset anymore
On Sun, May 06, 2001 at 07:27:16AM +, Alexander Koch wrote: [...] Should give me german umlauts and the prompts/messages should still be like before, right? Do I really not have to set ISO-8859-1 somewhere? You have to set it in /etc/locale.gen. Make sure that there is a line de_DE ISO-8859-1 without # in front of it. Then call locale-gen. -- CU, Patrick. Never run on auto-pilot - The Pragmatic Programmer pgpbC2HN16yaH.pgp Description: PGP signature
Re: Bug#95975: mutt: doesn't use charset anymore
On Sun, May 06, 2001 at 07:27:16AM +, Alexander Koch wrote: Just use LC_CTYPE=de_DE. It'll work fine in mutt. (The problem is, if I remember correctly, that X uses ISO8859-1, without the first dash.) Ok, but now I am confused... LC_CTYPE=de_DE LANG=de_DE LC_MESSAGES=C Should give me german umlauts and the prompts/messages should still be like before, right? Do I really not have to set ISO-8859-1 somewhere? Yes, because the locale alias file will assume ISO-8859-1 automatically. % grep ^de_DE' ' /usr/lib/X11/locale/locale.alias de_DE de_DE.ISO8859-1 -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#95975: mutt: doesn't use charset anymore
While we're at it: How on earth can I get rid of those Warning: locale not supported by Xlib, locale set to C messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts etc in mutt. Unfortunately, this produces the above error message with lots of X programs - especially annoying when you use at(1); you always get a mail with the error message. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯
Re: Bug#95975: mutt: doesn't use charset anymore
Richard == Richard Atterer [EMAIL PROTECTED] writes: Richard While we're at it: How on earth can I get rid of those Richard Warning: locale not supported by Xlib, locale set to C Richard messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts Richard etc in mutt. Unfortunately, this produces the above error Richard message with lots of X programs - especially annoying Richard when you use at(1); you always get a mail with the error Richard message. Just use LC_CTYPE=de_DE. It'll work fine in mutt. (The problem is, if I remember correctly, that X uses ISO8859-1, without the first dash.) The mutt docs are not very compatible with Xlib. Ben -- Brought to you by the letters C and H and the number 1. A squib is a firecracker. Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 11:20:21PM +0200, Richard Atterer wrote: [...] messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts etc in mutt. Try LC_CTYPE=de_DE instead. -- CU, Patrick. Never run on auto-pilot - The Pragmatic Programmer pgpzbiy9d7Pvs.pgp Description: PGP signature
Re: Bug#95975: mutt: doesn't use charset anymore
On 5 May 2001, Ben Gertzfield wrote: Richard == Richard Atterer [EMAIL PROTECTED] writes: Richard While we're at it: How on earth can I get rid of those Richard Warning: locale not supported by Xlib, locale set to C Richard messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts Richard etc in mutt. Unfortunately, this produces the above error Richard message with lots of X programs - especially annoying Richard when you use at(1); you always get a mail with the error Richard message. Just use LC_CTYPE=de_DE. It'll work fine in mutt. (The problem is, if I remember correctly, that X uses ISO8859-1, without the first dash.) The mutt docs are not very compatible with Xlib. In fact, this is bug 76906. On my sid machine, still not solved... -- Jean-Christophe Dubacq -- ATER en informatique à l'université de Caen Tel: 02 31 56 74 30 / 06 67 67 69 15 / 02 31 93 62 24 Email: [EMAIL PROTECTED] http://www.info.unicaen.fr/~jcdubacq/ Adresse: Jean-Christophe Dubacq, GREYC, Université de Caen, 14032 Caen Cedex
Re: Bug#95975: mutt: doesn't use charset anymore
On Thu 03 May 2001, Michael Stone wrote: On Thu, May 03, 2001 at 05:51:53PM -0700, Ben Gertzfield wrote: Paul == Paul Seelig [EMAIL PROTECTED] writes: Paul I think that *mutt* is definitely broken in this regard, Paul because *no* other console program i know (e.g. mc or pine) Paul breaks like this using the very same libc. It's not just mutt. GTK+ has the same problem. ls does the same thing. It's a fact of life; locales need to be configured if you're not working in 7bit ASCII. Sure, whatever, but *my* original point is that there is a setting in mutt, namely charset, which is documented to tell mutt what character set the terminal is capable of displaying and entering. This used to work fine, but suddenly it doesn't anymore even though the docs have not changed one iota in this respect. I'd suggest that as long as the charset setting is still supported in mutt, mutt should use that to override an absence of any locale settings (as it in fact did in the past, effectively). Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.org/
Re: Bug#95975: mutt: doesn't use charset anymore
On Thu, May 03, 2001 at 11:35:53PM -0400, Michael Stone wrote: The solution is to get LANG set to at least en_US by default for everyone, as LANG=C is just not useful any more. Changing the LANG to en_US may have some unexpected side effects and should not be done without at least some thought for the consequences. (E.g., the sort order will be radically different.) Hear, hear, the thing with the sort order is so annoying. But I guess we'll just have to get used to it :( -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#95975: mutt: doesn't use charset anymore
Josip Rodin schrieb: Changing the LANG to en_US may have some unexpected side effects and should not be done without at least some thought for the consequences. (E.g., the sort order will be radically different.) Hear, hear, the thing with the sort order is so annoying. But I guess we'll just have to get used to it :( hmm, what's LC_COLLATE for again? ciao, 2ri, running LANG=de_CH; LC_MESSAGES=C -- The light at the end of the tunnel is the headlight of an approaching train.
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 02:46:15PM +0200, Arthur Korn wrote: Changing the LANG to en_US may have some unexpected side effects and should not be done without at least some thought for the consequences. (E.g., the sort order will be radically different.) Hear, hear, the thing with the sort order is so annoying. But I guess we'll just have to get used to it :( hmm, what's LC_COLLATE for again? ? I was referring to this: % touch a b c .a .b .c A B C .A .B .C % LANG=C ls -A .A .B .C .a .b .c A B C a b c % LANG=hr_HR ls -A a .a A .A b .b B .B c .c C .C It acts as if the interpunction doesn't exist, which is just plain wrong! And it's not happening on potato. -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, 4 May 2001, Josip Rodin wrote: On Fri, May 04, 2001 at 02:46:15PM +0200, Arthur Korn wrote: Changing the LANG to en_US may have some unexpected side effects and should not be done without at least some thought for the consequences. (E.g., the sort order will be radically different.) Hear, hear, the thing with the sort order is so annoying. But I guess we'll just have to get used to it :( hmm, what's LC_COLLATE for again? ? I was referring to this: % touch a b c .a .b .c A B C .A .B .C % LANG=C ls -A .A .B .C .a .b .c A B C a b c % LANG=hr_HR ls -A a .a A .A b .b B .B c .c C .C It acts as if the interpunction doesn't exist, which is just plain wrong! And it's not happening on potato. However, $ LANG=hr_HR LC_COLLATE=C ls -A .A .B .C .a .b .c A B C a b c which was Arthur's point, I believe. Steve Langasek postmodern programmer
Re: Bug#95975: mutt: doesn't use charset anymore
Josip Rodin [EMAIL PROTECTED] writes: On Fri, May 04, 2001 at 02:46:15PM +0200, Arthur Korn wrote: ? I was referring to this: And Arthur was referring to the fact that you can set LANG=hr_HR and LC_COLLATE=C and get the old behavior. It acts as if the interpunction doesn't exist, which is just plain wrong! And it's not happening on potato. Whee, I switched to Debian in time to catch the fury here, too. Basically, the situation is: Take it up with the glibc developers or set LC_COLLATE. They aren't listening and nobody else can do anything. -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! Skiers go down fast.
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 09:38:06AM -0500, Steve Langasek wrote: Changing the LANG to en_US may have some unexpected side effects and should not be done without at least some thought for the consequences. (E.g., the sort order will be radically different.) Hear, hear, the thing with the sort order is so annoying. But I guess we'll just have to get used to it :( hmm, what's LC_COLLATE for again? ? I was referring to this: % touch a b c .a .b .c A B C .A .B .C % LANG=C ls -A .A .B .C .a .b .c A B C a b c % LANG=hr_HR ls -A a .a A .A b .b B .B c .c C .C It acts as if the interpunction doesn't exist, which is just plain wrong! And it's not happening on potato. However, $ LANG=hr_HR LC_COLLATE=C ls -A .A .B .C .a .b .c A B C a b c which was Arthur's point, I believe. Oh, so it's LC_COLLATE=hr_HR that's wrong. Thanks for telling me the workaround. -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 10:48:33AM -0400, Alan Shutko wrote: It acts as if the interpunction doesn't exist, which is just plain wrong! And it's not happening on potato. Whee, I switched to Debian in time to catch the fury here, too. Basically, the situation is: Take it up with the glibc developers or set LC_COLLATE. They aren't listening and nobody else can do anything. Geez. I've already filed a bug report in our bug tracking system (a couple of months ago IIRC). So if anyone notices it and is kind enough to patch it, we can have it fixed that way. -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#95975: mutt: doesn't use charset anymore
Am 4.05.01 um 16:28:16 schrieb Josip Rodin: It acts as if the interpunction doesn't exist, which is just plain wrong! Actually I'd expect my dictionary to be sorted exactly this way. And that's what LC_COLLATE is for. It's a different story that this behaviour is outright silly when in a shell. Bye, Mike -- |=| Michael Piefel[EMAIL PROTECTED] |=| Humboldt-Universität zu Berlin http://www.piefel.de |=| Tel. (+49 30) 2093 3831
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 05:17:33PM +0200, Michael Piefel wrote: It acts as if the interpunction doesn't exist, which is just plain wrong! Actually I'd expect my dictionary to be sorted exactly this way. A paper dictionary would never contain a word starting with a `.', at least not one written in my language :) -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 04:28:16PM +0200, Josip Rodin wrote: hmm, what's LC_COLLATE for again? ? I was referring to this: % touch a b c .a .b .c A B C .A .B .C % LANG=C ls -A .A .B .C .a .b .c A B C a b c % LANG=hr_HR ls -A a .a A .A b .b B .B c .c C .C It acts as if the interpunction doesn't exist, which is just plain wrong! And it's not happening on potato. it does not happen on woody either: (yet) [EMAIL PROTECTED]:/tmp/LC]% touch a b c .a .b .c A B C .A .B .C [EMAIL PROTECTED]:/tmp/LC]% LANG=C ls -A .A .B .C .a .b .c A B C a b c [EMAIL PROTECTED]:/tmp/LC]% LANG=hr_HR ls -A .A .B .C .a .b .c A B C a b c -john
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 09:03:18AM -0700, John H. Robinson, IV wrote: [EMAIL PROTECTED]:/tmp/LC]% LANG=hr_HR ls -A .A .B .C .a .b .c A B C a b c Probably because your locale.gen isn't configured to build an hr_HR locale. -- Mike Stone
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 12:30:36PM -0400, Michael Stone wrote: On Fri, May 04, 2001 at 09:03:18AM -0700, John H. Robinson, IV wrote: [EMAIL PROTECTED]:/tmp/LC]% LANG=hr_HR ls -A .A .B .C .a .b .c A B C a b c Probably because your locale.gen isn't configured to build an hr_HR locale. yep. exactly correct. what was that latin word for doh!? -john
Re: Bug#95975: mutt: doesn't use charset anymore
On May 04, Ben Gertzfield [EMAIL PROTECTED] wrote: It's not just mutt. GTK+ has the same problem. The solution is to Every application using gettext has the same problem. -- ciao, Marco
Re: Bug#95975: mutt: doesn't use charset anymore
On May 04, Paul Slootman [EMAIL PROTECTED] wrote: Sure, whatever, but *my* original point is that there is a setting in mutt, namely charset, which is documented to tell mutt what character set the terminal is capable of displaying and entering. This used to That's correct. It's used to set the charset attribute of the Content-Type header. Nothing else. It does *NOT* do what you think it does. work fine, but suddenly it doesn't anymore even though the docs have not changed one iota in this respect. I'd suggest that as long as the This used to work only because you use latin-1, i.e. you did not need a $LC_CTYPE value anyway. charset setting is still supported in mutt, mutt should use that to override an absence of any locale settings (as it in fact did in the past, effectively). It did not. -- ciao, Marco
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 04:26:12PM +, Lars Wirzenius wrote: A paper dictionary would never contain a word starting with a `.', at least not one written in my language :) Even if it explains the term .com? :) You got me there. :) -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 05:17:33PM +0200, Michael Piefel wrote: Am 4.05.01 um 16:28:16 schrieb Josip Rodin: It acts as if the interpunction doesn't exist, which is just plain wrong! Actually I'd expect my dictionary to be sorted exactly this way. And that's what LC_COLLATE is for. It's a different story that this behaviour is outright silly when in a shell. I'm not sure I would expect my dictionary to be sorted this way. In any case, many dictionaries are sorted in arbitrary, non-lexical manners. Unix doesn't need to emulate that; Unix needs a reasonable sort order that works for a shell and keeps an alphabetic order people (of that language) would consider reasonable. If sorting the dots in made more people happy than not, it would be good, but most of us seem to not care in most sorting situations, except the shell where it's a pain. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored. - Joseph_Greg
Re: Bug#95975: mutt: doesn't use charset anymore
On May 02, Paul Slootman [EMAIL PROTECTED] wrote: Well, (as I wrote), mutt's manual.txt says that the charset setting is used for that. This is your interpretation of the manual. So what's the point of the charset setting? After all, the manual.txt It tells mutt about which charaset you are typing. The exact quote from the docs is: Character set your terminal uses to display and enter textual data. Note the display in addition to enter. So not only: It tells mutt about which charaset you are typing. but also what can be displayed. Do you know any terminal type for which this is not the same? I agree it may be confusing, if you can think of a better wording please submit a patch to [EMAIL PROTECTED] (*) I really hate it when people close bugs with a one-liner (or less) answer, without any substantiating motivation. Especially when parts of That's fair. I have when people keep reporting this as a bug even after it has been discussed many times in many other bug reports. -- ciao, Marco
Re: Bug#95975: mutt: doesn't use charset anymore
On Thu, May 03, 2001 at 05:31:34PM +0200, Marco d'Itri wrote: On May 02, Paul Slootman [EMAIL PROTECTED] wrote: (*) I really hate it when people close bugs with a one-liner (or less) answer, without any substantiating motivation. Especially when parts of That's fair. I have when people keep reporting this as a bug even after it has been discussed many times in many other bug reports. Err, but it's a bit hard to find the other bug reports if you keep closing them! ;-) -S
Re: Bug#95975: mutt: doesn't use charset anymore
Paul == Paul Seelig [EMAIL PROTECTED] writes: Paul I think that *mutt* is definitely broken in this regard, Paul because *no* other console program i know (e.g. mc or pine) Paul breaks like this using the very same libc. It's not just mutt. GTK+ has the same problem. The solution is to get LANG set to at least en_US by default for everyone, as LANG=C is just not useful any more. Owen Taylor, the GTK+ developer, has confirmed that this is a libc6 2.2 issue. It just drops high ASCII characters for LANG=C now. Ben -- Brought to you by the letters P and O and the number 13. If you turn both processors off, you will have to reboot. Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
Re: Bug#95975: mutt: doesn't use charset anymore
On Thu, May 03, 2001 at 05:51:53PM -0700, Ben Gertzfield wrote: Paul == Paul Seelig [EMAIL PROTECTED] writes: Paul I think that *mutt* is definitely broken in this regard, Paul because *no* other console program i know (e.g. mc or pine) Paul breaks like this using the very same libc. It's not just mutt. GTK+ has the same problem. ls does the same thing. It's a fact of life; locales need to be configured if you're not working in 7bit ASCII. The solution is to get LANG set to at least en_US by default for everyone, as LANG=C is just not useful any more. LANG=C is useful for many people (works for me!) Changing the LANG to en_US may have some unexpected side effects and should not be done without at least some thought for the consequences. (E.g., the sort order will be radically different.) Setting only LC_CTYPE is a possibility, but that definately needs further discussion. -- Mike Stone
Re: Bug#95975: mutt: doesn't use charset anymore
reopen 95975 thanks Package: mutt Version: 1.3.15-2 Since upgrading to testing, mutt refuses to display iso-8859-1 high-bit characters such as u-umlaut (ü). Instead, \374 is displayed. :set charset shows charset=iso-8859-1; the message's Content-Type is: Content-Type: text/plain; charset=iso-8859-1 so that shouldn't be the problem. Hitting 'v' and then piping the message body through 'cat' displays it all correctly. RTFM README.Debian. Thanks for this eloquent explanation. So I should now set en environment variable to get mutt working the way it used to, which was a reasonable mode of operation. IMHO that's in violation of policy section 10.9: A program must not depend on environment variables to get reasonable defaults. So what's the point of the charset setting? After all, the manual.txt (which isn't a plain text file, but that's beside the point for this discussion) still states: 6.3.20. charset Type: string Default: Character set your terminal uses to display and enter textual data. Obviously it doesn't work that way anymore! So don't say I should read the FM, I F did. README.Debian is NOT a manual. manual.txt is. So fix the FM if the way it works has changed. Perhaps even give an error if charset is defined, as it apparently isn't used anymore. Paul Slootman
Re: Bug#95975: mutt: doesn't use charset anymore
close 95975 thanks On May 02, Paul Slootman [EMAIL PROTECTED] wrote: So I should now set en environment variable to get mutt working the way it used to, which was a reasonable mode of operation. IMHO that's in violation of policy section 10.9: A program must not depend on environment variables to get reasonable defaults. You'd better reassign this bug to libc then, guess what is mutt using to determine if a character is printable or not? So what's the point of the charset setting? After all, the manual.txt It tells mutt about which charaset you are typing. Obviously it doesn't work that way anymore! So don't say I should read It just does not work the way you think it does. -- ciao, Marco
Re: Bug#95975: mutt: doesn't use charset anymore
On Wed 02 May 2001, Marco d'Itri wrote: close 95975 I disagree about whether the bug is closed, as you forget to notice parts of my message. However, I don't feel like petty BTS games (*) On May 02, Paul Slootman [EMAIL PROTECTED] wrote: So I should now set en environment variable to get mutt working the way it used to, which was a reasonable mode of operation. IMHO that's in violation of policy section 10.9: A program must not depend on environment variables to get reasonable defaults. You'd better reassign this bug to libc then, guess what is mutt using to determine if a character is printable or not? Well, (as I wrote), mutt's manual.txt says that the charset setting is used for that. So what's the point of the charset setting? After all, the manual.txt It tells mutt about which charaset you are typing. The exact quote from the docs is: Character set your terminal uses to display and enter textual data. Note the display in addition to enter. So not only: It tells mutt about which charaset you are typing. but also what can be displayed. If that's no longer the case, at least fix the documentation! And perhaps add a note about the necessary environment variables. Obviously it doesn't work that way anymore! So don't say I should read It just does not work the way you think it does. Neither does it work the way it's documented. As this is a change from long-standing previous behaviour, I don't think you can skim over it in such a trivial manner. As a fortune quote says (paraphrasing): if the code and the comments disagree, both are wrong. I feel this also applies to the code and the documentation. (*) I really hate it when people close bugs with a one-liner (or less) answer, without any substantiating motivation. Especially when parts of the argumentation of the bug are ignored. What's the problem with leaving the bug open until the discussion is closed? Such behaviour is pretty childish. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.org/
