Ralph Corderoy <ralph(_at_)inputplus(_dot_)co(_dot_)uk> writes:
If you just have one long-running Emacs then can't that be in the UTF-8
locale? Or is your C-needing ls(1) run from inside that?
I'd rather not run it in non-C locale (for one thing, as you say, shells
run inside it would tend to inherit that locale). And I don't really
see what that would change anyway. The nmh calls are made from exmh,
which is a sibling not a child of the emacs process.
For the moment, I've worked around the problem by launching exmh (and
nothing else) in en_US.utf8 locale, so that the nmh calls all inherit
that. But I regard that as a hack not a fix. It affects directory
listings done by exmh, e.g. in save-to-file dialogs, and there may be
other side-effects as well; I haven't been using this workaround for
long enough to know. If it's decided that there will be no solution
provided at the nmh level, I'll probably look into injecting extra
code to set the locale envvars in exmh's nmh calls.
Have Emacs highlight non-ASCII characters in that mode wherever they
come from, e.g. paste from web browser? Have a function that maps the
common ones to ASCII, perhaps using recode(1)? Filter the buffer when
writing the file, erroring if it can't be written? Then you can send
valid US-ASCII emails.
All of these solutions presuppose that this is my problem and not the
software's. I respectfully disagree. I would like it to "just work"
whether or not there are stray UTF8 characters.
regards, tom lane
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers