Re: Mutt showing ? in place of space
On Sat, Mar 30, 2024 at 11:21:21AM -0700, googly.negotiator...@aceecat.org wrote: > ...this type of issue is really tricky because one has to be sure to > *build* against the packaged (i.e. non-base) libraries, including > cases like libncurses. IIRC this is far from automatic, some packages > as shipped link with the base ncurses. One has to inspect the package > build. Yeah. Getting this right is so ridiculously complex that even remembering all the things that you might need to check is genuinely challenging. This is why we really need a detailed FAQ that addresses all the things. I've sat down to write one several times, but I always get interrupted by something that seems to matter more at the time, so it hasn't happened. -_- -- Derek D. Martinhttp://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. signature.asc Description: PGP signature
Re: Mutt showing ? in place of space
On Sat, Mar 30, 2024 at 09:21:53AM -0400, Derek Martin wrote: > > "Programs in the OpenBSD base system ignore the locale except for > > the character encoding..." > Mutt is not part of the "base system" so the limitation on locale > should not apply to it, and "except for the character encoding" > absolutely SHOULD apply, since that is specifically what is at issue > in your case. In my various attempts to try and learn more about the *BSDs, which happen periodically when the sky seems to be falling on Linux, I found that this type of issue is really tricky because one has to be sure to *build* against the packaged (i.e. non-base) libraries, including cases like libncurses. IIRC this is far from automatic, some packages as shipped link with the base ncurses. One has to inspect the package build. The same is true for homebrew and linuxbrew. -- Ian
Re: Mutt showing ? in place of space
Hello Derek, On 2024-03-30 09:21:53, Derek Martin wrote: > However I would point out that your own post said that you had left > LANG unset. Did you try setting LANG (and unsetting all the other > environment variables, and Mutt's charset variable) as I suggested? > Did you then also look at the output of the locale command to ensure > that the settings were correct, as expected based on that setting? > I'd love to see that output, to confirm or refute whether your system > is correctly honoring LANG, as its man page seems to say it should... > And then once you confirmed that locale was correct, did you then try > Mutt? I did. However, I set the LANG variable in .profile and .kshrc files, which I think was the problem. Because, LANG (and the rest) wasn't updated when in the new session. > In either case--whether you set only LANG or only LC_CTYPE--you should > not then need to set Mutt's character set, because it should get it > from LC_CTYPE (directly or indirectly through inheritance from LANG). You are right. Setting the charset in muttrc is not necessary. Basically, you were right on all counts. All I needed was to just set the LANG variable correctly in .xsession. Now it's working and my locale is: LANG=en_US.UTF-8 LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL= > If OpenBSD can't handle this, then perhaps that would make at least > part of an argument for why end users shouldn't use it as their > desktop OS... It was just me all along. OpenBSD is a fantastic desktop OS :) Thank you for your kind assistance. -- Sadeep Madurange PGP: 103BF9E3E750BF7E
Re: Mutt showing ? in place of space
Sandeep, On Sat, Mar 30, 2024 at 10:21:30AM +0800, Sadeep Madurange wrote: > On 2024-03-29 16:47:22, Derek Martin wrote: > > [*] Except in extremely rare and completely esoteric cases that apply > > only to experts... and by now should really apply to no one. > > Thank you for patiently explaining. That was very educational. This is > what I used to do on Linux in the past, though, without knowing why. > > Unfortunately, this doesn't seem to work on OpenBSD. So, perhaps this > qualifies as one of the esoteric cases. OpenBSD doesn't seem to pay much > attention to the LANG variable. Thw following is an excerpt from the > locale man page: I don't have an OpenBSD system to test on, so I can't investigate further, but I wouldn't think so, because: > "Programs in the OpenBSD base system ignore the locale except for the > character encoding..." Mutt is not part of the "base system" so the limitation on locale should not apply to it, and "except for the character encoding" absolutely SHOULD apply, since that is specifically what is at issue in your case. Reading the rest of the man page, I find some of the additional details should be applicable to your case as well: "If the value of LC_CTYPE ends in ‘.UTF-8’, programs in the OpenBSD base system ignore the beginning of it, treating for example zh_CN.UTF-8 exactly like en_US.UTF-8. Programs from packages(7) may however make a difference." Shocking antiquation aside, this certainly seems to suggest that the guts of what is necessary for Mutt to have what it needs for the locale to work correctly do exist on the system. And the behavior they describe isn't really all that different from what normally happens on modern systems with full locale support--the point of Unicode is that every language's character sets are available simultaneously, so from a charset perspective the actual language doesn't matter. The main difference here appears to be that their base system only has English translations, so it ignores other aspects of LANG. And then this: "LANG Fallback if any of the above is unset." This matches the behavior I explained already in my previous post... At least according to their man page, everything I described SHOULD work. In other words, according to their own man page, if you set LANG and leave the other variables unset, this should be exactly equivalent to setting LC_CTYPE for any library functions which honor that variable, i.e. ALL of the functions which Mutt uses to control that behavior. Separately, though not apparently related to any concerns you have, Mutt's translations are provided by Mutt--not the base system--so even that should work correctly if your locale is set properly. That said, setting only LC_CTYPE is fine, if you only care about using Unicode as your character set, and don't want the other behaviors related to e.g. date & time, money display, etc. to match whatever differences exist in a UTF-8 environment (in my experience with en_US.UTF-8 the only difference is default sort order, typically observable in the output of the ls command, and controlled specifically by LC_COLLATE). However I would point out that your own post said that you had left LANG unset. Did you try setting LANG (and unsetting all the other environment variables, and Mutt's charset variable) as I suggested? Did you then also look at the output of the locale command to ensure that the settings were correct, as expected based on that setting? I'd love to see that output, to confirm or refute whether your system is correctly honoring LANG, as its man page seems to say it should... And then once you confirmed that locale was correct, did you then try Mutt? In either case--whether you set only LANG or only LC_CTYPE--you should not then need to set Mutt's character set, because it should get it from LC_CTYPE (directly or indirectly through inheritance from LANG). All of this behavior that I've described is part of the POSIX standard, and has been for quite literally decades. If OpenBSD can't handle this, then perhaps that would make at least part of an argument for why end users shouldn't use it as their desktop OS... -- Derek D. Martinhttp://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. signature.asc Description: PGP signature
Re: Mutt showing ? in place of space
Hello Derek, On 2024-03-29 16:47:22, Derek Martin wrote: > On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote: > > Initially, LANG was unset and LC_CTYPE="C". The character encoding > > was US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and > > locale settings) to en_US.UTF-8. Then the ? changed to ?. So, looks > > like you are on to something. I will check this with OpenBSD > > community as well. > > > > In Xdefaults, I have set XTerm*utf-8 setting to true as well. > > Your problem is that these settings are not consistent (and you still > have this problem, because the "solution" proposed by Sirius is > incorrect--even if it appears to have solved your issue). By having > LANG unset, you've told your shell (and therefore everything started > by it) to use ASCII, but you've explicitly told xterm to use Unicode. > That's wrong. > > The TL;DR of this is: > > 1. You should NEVER need to set Mutt's charset explicitly. [*] > 2. Your shell, Mutt, and X should all inherit what they need from your >LANG environment variable, assuming it is set properly for your >system and environment (it definitely isn't in your case). > 3. Setting Mutt's charset may appear to "work" but it's not the >correct solution, because your shell and terminal settings are >still inconsistent. You'll have trouble with other things later if >you don't fix this. > > [*] Except in extremely rare and completely esoteric cases that apply > only to experts... and by now should really apply to no one. Thank you for patiently explaining. That was very educational. This is what I used to do on Linux in the past, though, without knowing why. Unfortunately, this doesn't seem to work on OpenBSD. So, perhaps this qualifies as one of the esoteric cases. OpenBSD doesn't seem to pay much attention to the LANG variable. Thw following is an excerpt from the locale man page: "Programs in the OpenBSD base system ignore the locale except for the character encoding, and it is not recommended to use any of these variables except that the following non-default setting is supported as an option: export LC_CTYPE=en_US.UTF-8" [1] [1] https://man.openbsd.org/locale.1 -- Sadeep Madurange PGP: 103BF9E3E750BF7E
Re: Mutt showing ? in place of space
On Fri, Mar 29, 2024 at 03:03:54PM -0700, Bob Crochelt wrote: > Thank you Derek! > Bob Crochelt No problem, glad I could help. I had to figure this stuff all out the hard way 20 years ago, when I moved to Korea and suddently needed to be able to type in both English and Korean... I've been answering it on this list ever since... seriously, see this post from 2006: https://marc.info/?l=mutt-users&m=114434601817142&w=2 Things were A LOT worse then--Unicode hadn't really been adopted very much in 2004. Some of the finer details of how (or rather where) to set those settings keep changing (in part because young developers can't leave well enough alone when a solution has been working for literally decades), and most people don't need to futz with fonts anymore since Unicode is the default everywhere now, and the modern font rendering libraries handle all this automatically--but the basics of the problem and its solution are still the same. In another such post I commented that this topic comes up often enough that it really ought to be a FAQ. Some day I'll take the time to collect the details in a bit better format and provide one... -- Derek D. Martinhttp://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. > On Fri, Mar 29, 2024, at 13:47, Derek Martin wrote: > > On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote: > >> Initially, LANG was unset and LC_CTYPE="C". The character encoding was > >> US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale > >> settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you > >> are on to something. I will check this with OpenBSD community as well. > >> > >> In Xdefaults, I have set XTerm*utf-8 setting to true as well. > > > > Your problem is that these settings are not consistent (and you still > > have this problem, because the "solution" proposed by Sirius is > > incorrect--even if it appears to have solved your issue). By having > > LANG unset, you've told your shell (and therefore everything started > > by it) to use ASCII, but you've explicitly told xterm to use Unicode. > > That's wrong. > > > > The TL;DR of this is: > > > > 1. You should NEVER need to set Mutt's charset explicitly. [*] > > 2. Your shell, Mutt, and X should all inherit what they need from your > >LANG environment variable, assuming it is set properly for your > >system and environment (it definitely isn't in your case). > > 3. Setting Mutt's charset may appear to "work" but it's not the > >correct solution, because your shell and terminal settings are > >still inconsistent. You'll have trouble with other things later if > >you don't fix this. > > > > [*] Except in extremely rare and completely esoteric cases that apply > > only to experts... and by now should really apply to no one. > > > > > > The unfortunately lengthy details: > > -- > > > > Displaying characters properly is actually tricky business on modern > > computers, because of the legacy methods by which we tried to > > accommodate different languages, and the (relatively) recent advent of > > Unicode to unify that mess. All of the following must be set > > consistently: Your shell, your terminal program (or your operating > > system's console), your font, all of your application programs, and > > when appropriate, the X window system. If any of these are not > > consistently set, you can, and eventually WILL, have trouble. Most > > modern systems have the concept of a default locale, which is > > typically set for you at install time, and which every process you > > start inherits, unless you configure your user environment > > differently. > > > > Fortunately, there is a very simple mechanism by which this happens, > > which is the LANG environment variable. There are additional > > ancillary environment variables which start with "LC_*" but you > > usually should not have to set any of these, because they inherit > > their value from LANG if they are not explicitly set. When you run > > the locale command, values enclosed in quotes are inherited from LANG, > > and values NOT enclosed in quotes have been set explicitly: > > > > $ locale > > LANG=en_US.UTF-8 > > LANGUAGE= > > LC_CTYPE="en_US.UTF-8" > > LC_NUMERIC="en_US.UTF-8" > > LC_TIME="en_US.UTF-8" > > LC_COLLATE=C > > LC_MONETARY="en_US.UTF-8" > > LC_MESSAGES="en_US.UTF-8" > > LC_PAPER="en_US.UTF-8" > > LC_NAME="en_US.UTF-8" > > LC_ADDRESS="en_US.UTF-8" > > LC_TELEPHONE="en_US.UTF-8" > > LC_MEASUREMENT="en_US.UTF-8" > > LC_IDENTIFICATION="en_US.UTF-8" > > LC_ALL= > > > > Here you can see that I explicitly set LC_COLLATE=C. The rest are > > inherited from LANG. Typically most us
Re: Mutt showing ? in place of space
Thank you Derek! Bob Crochelt On Fri, Mar 29, 2024, at 13:47, Derek Martin wrote: > On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote: >> Initially, LANG was unset and LC_CTYPE="C". The character encoding was >> US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale >> settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you >> are on to something. I will check this with OpenBSD community as well. >> >> In Xdefaults, I have set XTerm*utf-8 setting to true as well. > > Your problem is that these settings are not consistent (and you still > have this problem, because the "solution" proposed by Sirius is > incorrect--even if it appears to have solved your issue). By having > LANG unset, you've told your shell (and therefore everything started > by it) to use ASCII, but you've explicitly told xterm to use Unicode. > That's wrong. > > The TL;DR of this is: > > 1. You should NEVER need to set Mutt's charset explicitly. [*] > 2. Your shell, Mutt, and X should all inherit what they need from your >LANG environment variable, assuming it is set properly for your >system and environment (it definitely isn't in your case). > 3. Setting Mutt's charset may appear to "work" but it's not the >correct solution, because your shell and terminal settings are >still inconsistent. You'll have trouble with other things later if >you don't fix this. > > [*] Except in extremely rare and completely esoteric cases that apply > only to experts... and by now should really apply to no one. > > > The unfortunately lengthy details: > -- > > Displaying characters properly is actually tricky business on modern > computers, because of the legacy methods by which we tried to > accommodate different languages, and the (relatively) recent advent of > Unicode to unify that mess. All of the following must be set > consistently: Your shell, your terminal program (or your operating > system's console), your font, all of your application programs, and > when appropriate, the X window system. If any of these are not > consistently set, you can, and eventually WILL, have trouble. Most > modern systems have the concept of a default locale, which is > typically set for you at install time, and which every process you > start inherits, unless you configure your user environment > differently. > > Fortunately, there is a very simple mechanism by which this happens, > which is the LANG environment variable. There are additional > ancillary environment variables which start with "LC_*" but you > usually should not have to set any of these, because they inherit > their value from LANG if they are not explicitly set. When you run > the locale command, values enclosed in quotes are inherited from LANG, > and values NOT enclosed in quotes have been set explicitly: > > $ locale > LANG=en_US.UTF-8 > LANGUAGE= > LC_CTYPE="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_COLLATE=C > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_PAPER="en_US.UTF-8" > LC_NAME="en_US.UTF-8" > LC_ADDRESS="en_US.UTF-8" > LC_TELEPHONE="en_US.UTF-8" > LC_MEASUREMENT="en_US.UTF-8" > LC_IDENTIFICATION="en_US.UTF-8" > LC_ALL= > > Here you can see that I explicitly set LC_COLLATE=C. The rest are > inherited from LANG. Typically most users will want to leave all of > the LC_* variables unset, and inherit from LANG. > > I haven't tried a *BSD in a really long while, but if it doesn't ask > you for your default locale during install, or if you made a mistake > setting it up, then you should add the settings manually to your login > shell environment. If you're using UTF-8 (which you should be--by now > every modern OS uses it by default), the value of LANG should reflect > that. Pretty much no one should be using ASCII anymore (i.e. LANG > should NEVER be unset). The most portable way to do that would be to > include the following in BOTH .profile and .kshrc (or whatever file > you've set ENV to): > > LANG=en_US.UTF-8 > export LANG > > [See the Invocation section of the ksh man page for exact details of > which files you should put this in, but in general it's the ones I > said.] > > Of course if you are not using English, change en_US to whatever your > default language is, but you'll want to retain the ".UTF-8" portion. > > That *should* be sufficient to handle everything... however, there may > be additional places you'll need to add it for your X applications, > depending on exactly what OpenBSD does to initialize users' X > sessions. In general, the X startup stuff is supposed to make sure > that it sources the user's environment so that you don't need to > figure out which of the 17 different files you actually need to put > this stuff in... but over the years most vendors have bastardized how > X sessions start u
Re: Mutt showing ? in place of space
On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote: > Initially, LANG was unset and LC_CTYPE="C". The character encoding was > US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale > settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you > are on to something. I will check this with OpenBSD community as well. > > In Xdefaults, I have set XTerm*utf-8 setting to true as well. Your problem is that these settings are not consistent (and you still have this problem, because the "solution" proposed by Sirius is incorrect--even if it appears to have solved your issue). By having LANG unset, you've told your shell (and therefore everything started by it) to use ASCII, but you've explicitly told xterm to use Unicode. That's wrong. The TL;DR of this is: 1. You should NEVER need to set Mutt's charset explicitly. [*] 2. Your shell, Mutt, and X should all inherit what they need from your LANG environment variable, assuming it is set properly for your system and environment (it definitely isn't in your case). 3. Setting Mutt's charset may appear to "work" but it's not the correct solution, because your shell and terminal settings are still inconsistent. You'll have trouble with other things later if you don't fix this. [*] Except in extremely rare and completely esoteric cases that apply only to experts... and by now should really apply to no one. The unfortunately lengthy details: -- Displaying characters properly is actually tricky business on modern computers, because of the legacy methods by which we tried to accommodate different languages, and the (relatively) recent advent of Unicode to unify that mess. All of the following must be set consistently: Your shell, your terminal program (or your operating system's console), your font, all of your application programs, and when appropriate, the X window system. If any of these are not consistently set, you can, and eventually WILL, have trouble. Most modern systems have the concept of a default locale, which is typically set for you at install time, and which every process you start inherits, unless you configure your user environment differently. Fortunately, there is a very simple mechanism by which this happens, which is the LANG environment variable. There are additional ancillary environment variables which start with "LC_*" but you usually should not have to set any of these, because they inherit their value from LANG if they are not explicitly set. When you run the locale command, values enclosed in quotes are inherited from LANG, and values NOT enclosed in quotes have been set explicitly: $ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE=C LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= Here you can see that I explicitly set LC_COLLATE=C. The rest are inherited from LANG. Typically most users will want to leave all of the LC_* variables unset, and inherit from LANG. I haven't tried a *BSD in a really long while, but if it doesn't ask you for your default locale during install, or if you made a mistake setting it up, then you should add the settings manually to your login shell environment. If you're using UTF-8 (which you should be--by now every modern OS uses it by default), the value of LANG should reflect that. Pretty much no one should be using ASCII anymore (i.e. LANG should NEVER be unset). The most portable way to do that would be to include the following in BOTH .profile and .kshrc (or whatever file you've set ENV to): LANG=en_US.UTF-8 export LANG [See the Invocation section of the ksh man page for exact details of which files you should put this in, but in general it's the ones I said.] Of course if you are not using English, change en_US to whatever your default language is, but you'll want to retain the ".UTF-8" portion. That *should* be sufficient to handle everything... however, there may be additional places you'll need to add it for your X applications, depending on exactly what OpenBSD does to initialize users' X sessions. In general, the X startup stuff is supposed to make sure that it sources the user's environment so that you don't need to figure out which of the 17 different files you actually need to put this stuff in... but over the years most vendors have bastardized how X sessions start up, so you may have to look up or trace out how your system does it to make sure everything works correctly. So you might have to also add it to .xinitrc or .xsession or similar. Or, if it does not already, you could simply have your X init thingy source your .profile
Re: Mutt showing ? in place of space
On 2024-03-23 12:52:40, Sirius Rayner-Karlsson via Mutt-users wrote: > In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: > > On 2024-03-23 11:10:11, Sirius via Mutt-users wrote: > > > In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: > > > > When I view the following email in mutt, I see a bunch of > > > > question marks where the spaces are. I checked the codepoints > > > > and they all seem to be the normal space (0x20) character in the > > > > ASCII table. > > For reference, in my Debian Bookworm, I have the following: > > sirius?~?$?locale > LANG=sv_SE.UTF8 > LANGUAGE= > LC_CTYPE="sv_SE.UTF8" > LC_NUMERIC="sv_SE.UTF8" > LC_TIME="sv_SE.UTF8" > LC_COLLATE="sv_SE.UTF8" > LC_MONETARY="sv_SE.UTF8" > LC_MESSAGES="sv_SE.UTF8" > LC_PAPER="sv_SE.UTF8" > LC_NAME="sv_SE.UTF8" > LC_ADDRESS="sv_SE.UTF8" > LC_TELEPHONE="sv_SE.UTF8" > LC_MEASUREMENT="sv_SE.UTF8" > LC_IDENTIFICATION="sv_SE.UTF8" > LC_ALL= > > It may be that you just need to pop in the "set charset="utf-8"" in > your mutt config and you are good to go. Thanks for sharing your config. You're right. I needed to add "set charset=utf-8" to muttrc and set LC_CTYPE. The problem was I had set the latter in my .kshrc when I needed to set it in .xsession. It's all good now. > > Unlikely to be a problem with the font. I'm using DejaVu Sans Mono, > > which I used on Linux in the past without any problem. > > That should be a good font. If you are in the market for some other > good fonts, take a look at Monafont. Thanks for the tip. Always appreciate those :) It looks nice. I will give it a go. -- Sadeep Madurange PGP: 103BF9E3E750BF7E
Re: Mutt showing ? in place of space
In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: > On 2024-03-23 11:10:11, Sirius via Mutt-users wrote: > > In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: > > > When I view the following email in mutt, I see a bunch of question marks > > > where the spaces are. I checked the codepoints and they all seem to be > > > the normal space (0x20) character in the ASCII table. > > > > My initial guess is that this is not a mutt problem but rather a display > > problem related to your environment. What does your LANG and LC variables > > look like and what are your locale settings? If at all possible, run with > > UTF-8. > > Initially, LANG was unset and LC_CTYPE="C". The character encoding was > US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale > settings) to en_US.UTF-8. Then the ? changed to �. So, looks like you > are on to something. I will check this with OpenBSD community as well. For reference, in my Debian Bookworm, I have the following: sirius�~�$�locale LANG=sv_SE.UTF8 LANGUAGE= LC_CTYPE="sv_SE.UTF8" LC_NUMERIC="sv_SE.UTF8" LC_TIME="sv_SE.UTF8" LC_COLLATE="sv_SE.UTF8" LC_MONETARY="sv_SE.UTF8" LC_MESSAGES="sv_SE.UTF8" LC_PAPER="sv_SE.UTF8" LC_NAME="sv_SE.UTF8" LC_ADDRESS="sv_SE.UTF8" LC_TELEPHONE="sv_SE.UTF8" LC_MEASUREMENT="sv_SE.UTF8" LC_IDENTIFICATION="sv_SE.UTF8" LC_ALL= I run this in a WSL on Win11, but have this config replicated across Fedora, RHEL and Debian VMs and physical systems. In my .mutt/muttrc, I have the following set: set ascii_chars=yes set assumed_charset="utf-8:iso-8859-1:us-ascii" set charset="utf-8" set config_charset="utf-8" It may be that you just need to pop in the "set charset="utf-8"" in your mutt config and you are good to go. > In Xdefaults, I have set XTerm*utf-8 setting to true as well. > > > It could also be related to the font used in Xterm, so worth trying > > another font (preferably one that has a decent portion of the UTF-8 > > glyphs). > > Unlikely to be a problem with the font. I'm using DejaVu Sans Mono, > which I used on Linux in the past without any problem. That should be a good font. If you are in the market for some other good fonts, take a look at Monafont. > -- > Sadeep Madurange > PGP: 103BF9E3E750BF7E -- Kind regards, /S
Re: Mutt showing ? in place of space
On 2024-03-23 11:10:11, Sirius via Mutt-users wrote: > In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: > > When I view the following email in mutt, I see a bunch of question marks > > where the spaces are. I checked the codepoints and they all seem to be > > the normal space (0x20) character in the ASCII table. > > My initial guess is that this is not a mutt problem but rather a display > problem related to your environment. What does your LANG and LC variables > look like and what are your locale settings? If at all possible, run with > UTF-8. Initially, LANG was unset and LC_CTYPE="C". The character encoding was US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you are on to something. I will check this with OpenBSD community as well. In Xdefaults, I have set XTerm*utf-8 setting to true as well. > It could also be related to the font used in Xterm, so worth trying > another font (preferably one that has a decent portion of the UTF-8 > glyphs). Unlikely to be a problem with the font. I'm using DejaVu Sans Mono, which I used on Linux in the past without any problem. -- Sadeep Madurange PGP: 103BF9E3E750BF7E
Re: Mutt showing ? in place of space
In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: > Hello, > > When I view the following email in mutt, I see a bunch of question marks > where the spaces are. I checked the codepoints and they all seem to be > the normal space (0x20) character in the ASCII table. My initial guess is that this is not a mutt problem but rather a display problem related to your environment. What does your LANG and LC variables look like and what are your locale settings? If at all possible, run with UTF-8. It could also be related to the font used in Xterm, so worth trying another font (preferably one that has a decent portion of the UTF-8 glyphs). > This happens fairly often. Usually with git patches or emails hat > contain the output of commands like ifconfig that has indented blocks. > > Any ideas? I'm using OpenBSD and Xterm. > > - Forwarded message - > > Index: 75.html > === > RCS file: /cvs/www/75.html,v > retrieving revision 1.10 > diff -u -p -r1.10 75.html > --- 75.html 22 Mar 2024 11:08:09 -?? 1.10 > +++ 75.html 22 Mar 2024 15:22:40 - > @@ -408,6 +408,7 @@ to 7.5. > JDK 8u402, 11.0.22, 17.0.10 and 21.0.2 > KDE Applications 23.08.4 > KDE Frameworks 5.115.0 > +?? KDE Plasma 5.27.10 > Krita 5.2.2 > LLVM/Clang 13.0.0, 16.0.6 and 17.0.6 > LibreOffice 24.2.1.2 > > - End forwarded message - > > -- > Sadeep Madurange > PGP: 103BF9E3E750BF7E -- Kind regards, /S
