Re: Threading + Locale woes
On Sun, Dec 02, 2012 at 08:37:18PM +, Jamie Paul Griffin wrote: > * Will Yardley [2012-12-02 11:00:56 -0800]: > > > On Sun, Dec 02, 2012 at 09:41:02AM -0600, fREW Schmidt wrote: > > > (http://dev.mutt.org/trac/wiki/MuttFaq/Charset) and setting > > > > > >export LC_CTYPE=en_US.ISO-8859-1 > > > > > > did fix the problem, but it also causes perl to scream and shout about > > > an unsupported locale. > > [...] > > > Here is the output of `locale -a`: > > > > So, looks like your system only has UTF8 locales installed. Havey ou > > tried setting $LC_CTYPE to en_US.utf8? The ACS characters work fine for > > me in UTF8 locales. > > > > You may also want to experiment with terminal settings and fonts. What > > terminal emulator and what value of $TERM are you using? > > > > w > > There are a number of things to check and set to get this working. It > can be a bit of a PITA sometimes. > > Perl only complains if the LC_* you've set isn't on the system. For > example: on my system (BSD type) in /usr/share/locales/en_US.UTF-8/ > there is only LC_CTYPE - so I set that. Had I set LC_MESSAGES, ... , > then perl would display those annoying errors (which can be turned off > by the way) as the option is not available on my system. I understand that they can be turned off, I just figured it was a good canary (as it did break other more important things.) > If you're using startx to start your X session, it's recommended > to add the locale setting to ~/.xinitrc so it's in the environment > already before opening any terminals, etc. I guess it wouldn't hurt to > put it in ~/.xsession either, if you're using a display manager to start > your X session. As you're using Ubuntu, I guess you are. You are correct, I am using a display manager. The env vars are certainly not set for the entire X session, but they are set for every program that I run as I set up my run command to source my .zshrc https://github.com/frioux/dotfiles/blob/4efc7741f98e6771948f5806ed59fb483347de43/bin/showdm I just hate hate hate restarting X to fiddle with something like this. > I also had to make sure I installed a proper unicode-aware terminal > emulator, and I use urxvt for that. Further, I have installed certain > fonts and use these in my ~/.Xdefaults file; these fonts support unicode > characters. Normally I use terminator but just to keep things simple while trying to get this to work I installed urxvt (256 color version.) I'm using tmux in general so my TERM is set to screen-256color. I set it to xterm to see if that would make a difference and frustratingly I had no luck. I also tried rxvt-unicode-256color. The font I use in general is terminus, I don't see any documentation anywhere as to whether it supports unicode, but outside of mutt I've always been able to use unicode directly (vim, zsh, git.) (Anecdotal evidence: just yesterday I wrote a commit message with the intersection character.) > So, the things to make sure you have set up are: > > set the locale to a locale that is available on your system I've tried each and both of the following: export LC_CTYPE=en_US.utf8 export LANG=en_US.utf8 > set it in your shell configuration file and X startup file Done. (Assuming all programs that are run from X having said env vars set is sufficient.) > use a terminal emulator that is unicode aware Done. (urxvt-256color) > with linux, you should be able to set LANG=whatever; Done. > otherwise, check what LC_* are available. There are a number of them, but LANG=en_US.utf8 is set by the system already and the shell (zsh) says all other LC_* are for overriding LANG. > check your shell's documentation with regards to locales > > Another thing to check is /etc/login.conf. You can set these environment > options in there, followed by a run of cap_mkdb /etc/login.conf if you > change anything in there. (I'm not sure if Linux uses this, I don't use > Linux systems at all so I don't know.) > > These are things I've needed to do, some of these steps may not be > necessary on Linux but hopefully it will help you or at least give you > an idea of what to look for. So I'm out of ideas and suggestions :/ The only thing I can think of at this point is that I compiled mutt myself, but I just looked at the configure opts and it doesn't look like I could have accidentally disabled utf8 support. -- fREW Schmidt http://blog.afoolishmanifesto.com pgpnQtRPE9vjO.pgp Description: PGP signature
Re: Threading + Locale woes
On Tue, Dec 04, 2012 at 01:17:22PM -0600, fREW Schmidt wrote: > > If you're using startx to start your X session, it's recommended > > to add the locale setting to ~/.xinitrc so it's in the environment > > already before opening any terminals, etc. I guess it wouldn't hurt to > > put it in ~/.xsession either, if you're using a display manager to start > > your X session. As you're using Ubuntu, I guess you are. > > You are correct, I am using a display manager. The env vars are > certainly not set for the entire X session They really need to be. Otherwise any program that's started by, say, your window manager's menus will actually be started using your system's default locale, rather than the one you configured (though to be fair, this is somewhat system-dependent... it's possible your X window system may include the user's environment files, and IMO it always should, for exactly this reason). For instance, if you're using xterm from a window manager widget, and the locale it was started with does not match the locale you're using, you are fairly certain to encounter problems. If your system's default locale is "C" and you're actually using something.utf8, xterm will be expecting characters uniformly of 8 bits, but will be fed variable-width characters, and will misinterpret them. You mostly won't notice if you're an English speaker and only using letters and numbers and common punctuation, but once you get outside that you'll start noticing wierd things. > > with linux, you should be able to set LANG=whatever; > > Done. LANG is, IIRC, part of the posix standard for internationalization, so it should be available pretty much everywhere. The LC_* variables inherit the value of LANG if you do not explicitly set them, so in general this is all you should ever need to set. Though, some oddball systems may differ (but all Linux distros work this way). > > check your shell's documentation with regards to locales It's not likely to actually be a function of the shell, except inasmuch as the shell propagates environment variables. It's really more a function of the libc on the system. There's usually a man page for this in section 7, i.e.: $ man 7 locale > So I'm out of ideas and suggestions :/ The only thing I can think of > at this point is that I compiled mutt myself, but I just looked at the > configure opts and it doesn't look like I could have accidentally > disabled utf8 support. I missed the start of the thread, so I don't know if this was covered. UTF-8 requires wide character support. On older distros, you only got this if you installed ncursesw (and ncursesw-dev(el)), though it seems like more recent distros are only providing the wide version (as ncurses, sans the 'w'). So that could be an issue. If your distro has no ncursesw* packages, then it probably is NOT the problem. If you haven't already included it, the output of mutt -v may be helpful. -- 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. pgp5PLLhyqq8q.pgp Description: PGP signature
Re: Threading + Locale woes
On Tue, Dec 04, 2012 at 02:32:53PM -0600, Derek Martin wrote: > On Tue, Dec 04, 2012 at 01:17:22PM -0600, fREW Schmidt wrote: > > > If you're using startx to start your X session, it's recommended > > > to add the locale setting to ~/.xinitrc so it's in the environment > > > already before opening any terminals, etc. I guess it wouldn't hurt to > > > put it in ~/.xsession either, if you're using a display manager to start > > > your X session. As you're using Ubuntu, I guess you are. > > > > You are correct, I am using a display manager. The env vars are > > certainly not set for the entire X session > > They really need to be. Otherwise any program that's started by, say, > your window manager's menus will actually be started using your > system's default locale, rather than the one you configured (though to > be fair, this is somewhat system-dependent... it's possible your X > window system may include the user's environment files, and IMO it > always should, for exactly this reason). > > For instance, if you're using xterm from a window manager widget, and > the locale it was started with does not match the locale you're using, > you are fairly certain to encounter problems. If your system's > default locale is "C" and you're actually using something.utf8, xterm > will be expecting characters uniformly of 8 bits, but will be fed > variable-width characters, and will misinterpret them. You mostly > won't notice if you're an English speaker and only using letters and > numbers and common punctuation, but once you get outside that you'll > start noticing wierd things. Right, I understand, but that tiny script I link to is the only "widget" I use to start other programs. > > > with linux, you should be able to set LANG=whatever; > > > > Done. > > LANG is, IIRC, part of the posix standard for internationalization, so > it should be available pretty much everywhere. The LC_* variables > inherit the value of LANG if you do not explicitly set them, so in > general this is all you should ever need to set. Though, some oddball > systems may differ (but all Linux distros work this way). > > > > check your shell's documentation with regards to locales > > It's not likely to actually be a function of the shell, except > inasmuch as the shell propagates environment variables. It's really > more a function of the libc on the system. There's usually a man page > for this in section 7, i.e.: > > $ man 7 locale > > > So I'm out of ideas and suggestions :/ The only thing I can think of > > at this point is that I compiled mutt myself, but I just looked at the > > configure opts and it doesn't look like I could have accidentally > > disabled utf8 support. > > I missed the start of the thread, so I don't know if this was covered. > UTF-8 requires wide character support. On older distros, you only got > this if you installed ncursesw (and ncursesw-dev(el)), though it seems > like more recent distros are only providing the wide version (as > ncurses, sans the 'w'). So that could be an issue. If your distro > has no ncursesw* packages, then it probably is NOT the problem. If > you haven't already included it, the output of mutt -v may be helpful. Eureka! And that solved it! Sorry for not mentioning the building of mutt already. libncursesw5-dev installed from aptitude and a rebuild of mutt fixed it. Thanks everyone! -- fREW Schmidt http://blog.afoolishmanifesto.com pgpYzO6h8cITq.pgp Description: PGP signature
on-demand rewrap received mail and display in builtin pager
Hi Guys, I read the last long discussion about line wrapping and proper mail formatting. Sadly I am on a few mailinglists and in contact with some people that strictly refuse to write nicely formatted mails. So my next idea was to rewrap the received message on demand, once I notice that I don't want to read the ugly mail. But I really like the formatting of the buildin pager, so I think a macro for " | par | less " is possible, but I loose the tight integration and cool look of the buildin pager. Is there any way to pipe a "builtin pager buffer" (the final output with verified signatures etc) to a process and reread the output to the buildin pager. I just skimmed the mutt manpage and the fine manual once again, but nothing caught my attention that it could work. Thanks and kind regards, Andre -- Andre Klärner smime.p7s Description: S/MIME cryptographic signature
Re: on-demand rewrap received mail and display in builtin pager
On Tue, Dec 04, 2012 at 10:39:30PM +0100, Andre Klärner wrote: > Hi Guys, > > I read the last long discussion about line wrapping and proper mail > formatting. All of it? You are a braver man than I :) > Is there any way to pipe a "builtin pager buffer" (the final output > with verified signatures etc) to a process and reread the output to the > buildin pager. > > I just skimmed the mutt manpage and the fine manual once again, but nothing > caught my attention that it could work. perhaps display_filter would work? http://www.mutt.org/doc/manual/manual-6.html#display_filter alternatively, you could reformat the mails at receive time through a procmail filter or something if you have that kind of access to the mail server. -Jeremy pgpVS73HtRQ1x.pgp Description: PGP signature
Re: Threading + Locale woes
On Tue, Dec 04, 2012 at 02:41:25PM -0600, fREW Schmidt wrote: > > On older distros, you only got this if you installed ncursesw (and > > ncursesw-dev(el)), though it seems like more recent distros are > > only providing the wide version (as ncurses, sans the 'w'). Incidentally, this may (or may not) be wrong. I missed them because I forgot about the lib*ncurses* packages, and my search didn't catch them. It may still be true, but if so I got it right only by accident, and I don't have handy a very recent distro against which to check. > > that could be an issue. If your distro has no ncursesw* packages, > > then it probably is NOT the problem. If > > you haven't already included it, the output of mutt -v may be helpful. > > Eureka! And that solved it! Sorry for not mentioning the building of > mutt already. libncursesw5-dev installed from aptitude and a rebuild > of mutt fixed it. No problem. Been there... was bitten by this more than once. [I've been building Mutt with UTF-8 support for just about as long as that has been possible in Linux.] =8^) -- 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. pgphuK1VAVYfD.pgp Description: PGP signature
Re: Using .muttrc while sending messages from command line
On Tue, Dec 04, 2012 at 05:26:34PM -0500, Spangler, Tim wrote: I have several automated processes that send e-mail from the command line, and I'd like each one to use its own .muttrc. This would allow me to specify the return address for each of these sets of e-mails based on the process sending it. Here is the sample command I'm using to test: echo "Testing to see if I loaded client 2's muttrc" | mutt -F ~/Muttrc_client2 -n -s "Testing mutt commands" recipi...@domain.com Unfortunately the muttrc is not loaded, so all of the e-mail comes from *user*@hostname.domain.com. Can you post what is in your Muttrc_client* files? I just testing with: set from=f...@sigpipe.org in Muttrc-1 and it worked as expected (from: was set to f...@sigpipe.org) when I tried it.
Re: Using .muttrc while sending messages from command line
On 2012-12-04, Spangler, Tim wrote: > I have several automated processes that send e-mail from the command > line, and I'd like each one to use its own .muttrc. This would allow > me to specify the return address for each of these sets of e-mails > based on the process sending it. > > Here is the sample command I'm using to test: > echo "Testing to see if I loaded client 2's muttrc" | mutt -F > ~/Muttrc_client2 -n -s "Testing mutt commands" recipi...@domain.com Are you sure that the "-n" is needed? -n Causes Mutt to bypass the system configuration file. That may be telling mutt to ignore the configuration file that you're specifying with the -F options. I do the exact command above all the time (I have 4 different muttrc files. It always works fine for me without the "-n". -- Grant Edwards grant.b.edwardsYow! ! Everybody out of at the GENETIC POOL! gmail.com
Re: Using .muttrc while sending messages from command line
On Tue, Dec 04, 2012 at 06:41:28PM -0500, Spangler, Tim wrote: The Muttrc_client files look similar to this (file name for this one is Muttrc_batch): set realname="Batch Reports" set from ="donotre...@adpselect.com" set use_from=yes Which version of Mutt are you using?
Re: Using .muttrc while sending messages from command line
On Tue, Dec 04, 2012 at 11:50:47PM +, Grant Edwards wrote: Are you sure that the "-n" is needed? -n Causes Mutt to bypass the system configuration file. That may be telling mutt to ignore the configuration file that you're specifying with the -F options. The -n option only controls reading the system muttrc. Mutt will always attempt to use either the muttrc specified with -F or the user's personal muttrc (use -n -F /dev/null for no rc at all).
Re: Using .muttrc while sending messages from command line
On Tue, Dec 04, 2012 at 06:41:28PM -0500, Spangler, Tim wrote: The Muttrc_client files look similar to this (file name for this one is Muttrc_batch): set realname="Batch Reports" set from ="donotre...@adpselect.com" set use_from=yes I put the above in 'testrc' and then ran: $ echo 'hello world' | mutt -n -F testrc -s 'default subject' bo...@sigpipe.org This was the resulting email: Date: Tue, 4 Dec 2012 15:49:30 -0800 From: Batch Reports To: bo...@sigpipe.org Subject: default subject hello world Mutt 1.5.21
Re: on-demand rewrap received mail and display in builtin pager
On 04.12.12 14:00, Jeremy Kitchen wrote: > alternatively, you could reformat the mails at receive time through > a procmail filter or something if you have that kind of access to the > mail server. If anyone has a working solution, I'd be interested too. The following had to be commented out, because folded URLs and code patches weren't much use: # This DOES WRECK URLs! # This can wreck code patches: # :0Bbfw # Fold long lines (>80 col.) at a space: # * ... # | fold -s # # :0aBfw # if message was reformatted and it had a "Lines:" header # * H ?? ^Lines: # * 1^1 ^.*$ # * -1^0 # | formail -i "Lines: $=" Perhaps interpose a bit of awk to fold only if it's not a URL? At least that fixes one case. (And I don't receive many patches these days.) Erik -- On a clear disk you can seek forever. - P. Denning
