Lyndon wrote:
> I'll add it when if/when I need it.
How bout I change the LC_ALL in the setlocale() to
LC_CTYPE? Then you can override with $LC_ALL.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/n
> On Oct 19, 2016, at 5:51 PM, David Levine wrote:
>
> It's easy to add later if we need,
> hard to take away.
Carry on. I'll add it when if/when I need it.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo
Lyndon wrote:
> The overhead of $NMH_LANG isn't even measurable, and the code path is trivial.
Yes. But, I just don't want to burden the maintainers, and add
roughage to the documentation and test suite, for a feature that
I don't think will be used. It's easy to add later if we need,
hard to t
>> 1) command line (-locale)
>> 2) mh-command-specific profile entry (.mh-profile)
>> 3) environment ($NMH_LANG)
>> 4) profile default override (.mh-profile)
>> 5) OS environment default (locale())
>>
>> It's arguable about the ordering of (2) and (3). But if I really needed
>> this level of con
In a message of Wed, 19 Oct 2016 11:38:45 -0400, David Levine writes:
>I'll do 1), but the other steps would be up to you.
Thank you very much.
Laura
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-work
In a message of Wed, 19 Oct 2016 11:46:31 -0400, David Levine writes:
>OK. I'm not going to add a -locale switch, that seems to me to move this
>too close to nmh. I like the locale profile component. Let me ask those
>who might use it: do you also want the NMH_LANG environment variable? I'd
>r
David Levine writes:
> OK. I'm not going to add a -locale switch, that seems to me to move this
> too close to nmh. I like the locale profile component. Let me ask those
> who might use it: do you also want the NMH_LANG environment variable? I'd
> rather not add a feature that won't be used.
Lyndon wrote:
> I.e., the standard (MH-modified) UNIX model is:
>
> 1) command line (-locale)
> 2) mh-command-specific profile entry (.mh-profile)
> 3) environment ($NMH_LANG)
> 4) profile default override (.mh-profile)
> 5) OS environment default (locale())
>
> It's arguable about the ordering of
Laura wrote:
> And, of course, I do use attach at the What Now? prompt.
So, another approach to get what you want (8-bit message even if
it contains no 8-bit characters) would be to do all this:
1) Add support for locale profile component to nmh.
2) Use latest nmh (HEAD of master) or upcoming nm
And, of course, I do use attach at the What Now? prompt.
Laura
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Laura wrote:
> I don't know about Tom, but my problem isn't that I want to send valid
> US-ASCII emails, but that I _never_ want to send valid us-ascii emails.
> And the last thing I want to happen is for nmh to not be able to
> tell what I want, stick in us-ascii (because the thing needs a
> con
In a message of Tue, 18 Oct 2016 15:13:49 +0100, Ralph Corderoy writes:
>There's a mechanism for telling a hierarchy of programs their locale;
>environment variables. You're using it, but you're telling some of them
>a different locale to what you really want them to use.
People do this a lot aro
Hi Tom,
> All of these solutions presuppose that this is my problem and not the
> software's. I respectfully disagree.
Me too. :-)
There's a mechanism for telling a hierarchy of programs their locale;
environment variables. You're using it, but you're telling some of them
a different locale t
>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-effec
In a message of Tue, 18 Oct 2016 14:17:24 +0100, Ralph Corderoy writes:
>Hi Tom,
>
>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?
>
>Have Emacs highlight non-ASCII characters in that mode wherever they
>come from,
Ralph Corderoy 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 real
Hi Tom,
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?
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 ASCI
Ken Hornstein writes:
> As I understand it, Tom said his problem was when he forwarded some
> email to someone else and it contained 8-bit characters. I suspect this
> was done with "forw" (or the Forward button in exmh).
Just for the record, I didn't say that; I rarely use "forw". The more
com
ken wrote:
> >> (And it occurs to me that even setting the locale properly probably
> >> will not fix your specific problem, as you have described it;
> >> forwarding messages using MIME will).
> >
> >I don't think this got addressed. If a nmh-specific locale doesn't fix
> >the problem then
>But we aren't. I am saying UTF-8 is the native internal character
>set. What happens at the boundaries becomes everyone else's problem.
>And after all the grief in this discussion over the last five+ years,
>don't you think it should be someone else's problem?
Yeah, this is the part I don't under
>> (And it occurs to me that even setting the locale properly probably
>> will not fix your specific problem, as you have described it;
>> forwarding messages using MIME will).
>
>I don't think this got addressed. If a nmh-specific locale doesn't fix
>the problem then let's not add it.
As I under
Hi,
Ken wrote:
> And if we're voting ... I would rather have only one additional way to
> specify a nmh-specific locale (well, I'd rather have ZERO additional
> ways, but I think more than one way is overkill).
I'd rather have zero. :-) Anything above that surely warrants an
nmhlocale(1).
> (A
> On Oct 17, 2016, at 8:28 PM, Tom Lane wrote:
>
> The current state of affairs is that nmh unconditionally assumes that
> non-ASCII input is in the character set specified by the LC_CTYPE
> environment variable (modulo the various ways that that can be specified).
> What I'm suggesting would al
Ken Hornstein writes:
> I ... do not think this would solve this particular problem. The issue
> here seems to be a) nmh programs were given 8 bit characters, and b)
> the locale was set to US-ASCII. If you are going to assume that all
> INPUT is unconditionally UTF-8, then yes, that would solve
> On Oct 17, 2016, at 8:12 PM, Lyndon Nerenberg wrote:
>
>> If you are going to assume that all
>> INPUT is unconditionally UTF-8,
I don't. Sorry, I missed that on my original rant. LC_CTYPE is what we use
inbound to convert un-labelled characters to UTF-8. We still use UTF-8
everywhere, i
> If you are going to assume that all
> INPUT is unconditionally UTF-8, then yes, that would solve this problem.
> But you say above you want to use LANG/LC_CTYPE to convert to UTF-8 on
> input; that would have failed given the problem as stated.
Two problems:
1) original input from the nmh user
>i had the same issue, and decided that for me, it was the only thing
>in the way of changing fully to a UTF-8 locale. so i do this:
>
>$ locale
>LANG=en_US.UTF-8
>LANGUAGE=en_US:en
>LC_CTYPE=en_US.utf8
Turning this around ... all we really care about is LC_CTYPE. Everything
else
>If we were to use $LANG/$LC_CTYPE to convert incoming data to UTF-8
>in the same manner, and process (and store!) everything internally
>as UTF-8, all of this nonsense would go away. Similarly, we could
>convert from UTF-8 -> $LANG/$LC_CTYPE on the way out. And we could ship
>everything off-site
> On Oct 17, 2016, at 6:39 PM, Ken Hornstein wrote:
>
> What it refuses to do now is create improperly-formatted email messages
> when it cannot identify the character set. Before it would happily
> send these messages out; THAT has been broken for twenty years and was
> only recently fixed.
>
>Well, my problem is that I want the prevailing session locale to be C,
>primarily because I'm used to seeing output from e.g. "ls" in ASCII
>ordering. But I'm finding that nmh, or at least send, is effectively
>broken in that locale --- unwillingness to cope with non-ASCII data
>at all counts as
tom wrote:
> Lyndon Nerenberg writes:
> > At this point, I think the fact that nobody seems to be able to give a
> > simple, clear, and coherent description of the problem suggests that
> > nobody really knows what the actual problem is, yet.
>
> Well, my problem is that I want the prevai
Lyndon wrote:
> > On Oct 17, 2016, at 6:13 PM, David Levine wrote:
> >
> > I'm not a fan of environment variables when there's an alternative.
> > The profile seems like a good home.
>
> $NMH_LANG -> <.mh_profile> -> locale() seems like a reasonable hierarchy
> that covers pretty much any scenar
> On Oct 17, 2016, at 6:20 PM, Lyndon Nerenberg wrote:
>
> $NMH_LANG -> <.mh_profile> -> locale() seems like a reasonable hierarchy that
> covers pretty much any scenario.
I.e., the standard (MH-modified) UNIX model is:
1) command line (-locale)
2) mh-command-specific profile entry (.mh-profi
Lyndon Nerenberg writes:
> At this point, I think the fact that nobody seems to be able to give a
> simple, clear, and coherent description of the problem suggests that nobody
> really knows what the actual problem is, yet.
Well, my problem is that I want the prevailing session locale to be C,
> On Oct 17, 2016, at 6:13 PM, David Levine wrote:
>
> I'm not a fan of environment variables when there's an alternative.
> The profile seems like a good home.
$NMH_LANG -> <.mh_profile> -> locale() seems like a reasonable hierarchy that
covers pretty much any scenario.
--lyndon
__
> On Oct 17, 2016, at 6:08 PM, Ken Hornstein wrote:
>
>> What about an $NMH_LANG environment variable that the runtime could
>> look for *very* early on, and use to seed $LANG. Seems like minimal
>> impact to the rest of the code that's locale aware. Assuming that is
>> all consolidated in the
Lyndon wrote:
> What about an $NMH_LANG environment variable that the runtime
> could look for *very* early on, and use to seed $LANG.
I'm not a fan of environment variables when there's an alternative.
The profile seems like a good home.
> Seems like minimal impact to the rest of the code that'
Ken wrote:
> >[Tom wrote:]
> >I thought Laura's suggestion was to be able to put something like
> >
> >locale: en_GB.utf8
> >
> >into ~/.mh_profile, which seems eminently sensible to me.
>
> Sigh. I won't object if someone does this work ... but it's not something
> I want to tackle, for the afor
>What about an $NMH_LANG environment variable that the runtime could
>look for *very* early on, and use to seed $LANG. Seems like minimal
>impact to the rest of the code that's locale aware. Assuming that is
>all consolidated in the library routines. Which I *think* we are ...
Uhhh ... see
> On Oct 17, 2016, at 5:54 PM, Ken Hornstein wrote:
>
>> I thought Laura's suggestion was to be able to put something like
>>
>> locale: en_GB.utf8
>>
>> into ~/.mh_profile, which seems eminently sensible to me.
>
> Sigh. I won't object if someone does this work ... but it's not something
>
>I thought Laura's suggestion was to be able to put something like
>
>locale: en_GB.utf8
>
>into ~/.mh_profile, which seems eminently sensible to me.
Sigh. I won't object if someone does this work ... but it's not something
I want to tackle, for the aforementioned reasons. Note that it's not
com
Ken Hornstein writes:
>> I believe that nmh users are sophisticated enough that they actually
>> know what a Locale is, and an encoding, and if they google for more
>> information they will understand what they read. I think that they
>> are going to want a way to specify what they want in their
>I believe that nmh users are sophisticated enough that they actually
>know what a Locale is, and an encoding, and if they google for more
>information they will understand what they read. I think that they
>are going to want a way to specify what they want in their mh_profile
>though.
Wlll .
In a message of Mon, 17 Oct 2016 17:21:18 -0400, Ken Hornstein writes:
>I agree that we can't reasonably know what the character set is supposed
>to be in that case. But I would say that given the choice between
>sending 'something wrong' and 'erroring out', 'erroring out' is the more
>correct opt
Hi Ken,
> > Valid UTF-8 and valid GB2312 can share the same sequences,
> > especially if it's just the odd `£' or `拢` in ASCII text.
>
> It was just a suggestion, not one I was particularly crazy about ...
> but not all arbitrary 8-bit sequences are valid UTF-8.
Oh, agreed.
> And it looks like f
In a message of Mon, 17 Oct 2016 21:41:08 +0100, Ralph Corderoy writes:
>Hi Laura,
>
>> Just giving them utf-8 even though that wasn't what they asked for has
>> fixed a huge number of headaches when running mailing lists around
>> here.
>
>Does that mailing-list software check that what they're se
>BTW, WRT spotting multi-byte UTF-8 encoding, I don't think that's a
>goer. Valid UTF-8 and valid GB2312 can share the same sequences,
>especially if it's just the odd `£' or `拢` in ASCII text.
It was just a suggestion, not one I was particularly crazy about ... but
not all arbitrary 8-bit sequen
>Well, whether you intentionally type any and whether some happen to creep
>into your email are two different things. As an example: I am suspicious
>now that my problem really stemmed from exmh choosing to use both -push
>and -forward; the latter is documented as "If -forward is given, then a
>co
>The problem is that most of the time people who have the locale US-ASCII
>set do so when what they want is 'English, US or Brit doesn't matter,
>but keep all the extra characters that other people are using when,
>for instance writing their names'. They don't want their mail to fall over
>because
Hi Laura,
> Just giving them utf-8 even though that wasn't what they asked for has
> fixed a huge number of headaches when running mailing lists around
> here.
Does that mailing-list software check that what they're sending out is
valid for the encoding they claim, UTF-8? Or when replying to an
In a message of Mon, 17 Oct 2016 13:42:37 -0400, Ken Hornstein writes:
>Also, it kind of strikes me as the wrong solution, and not just because
>of the additional complexity. The locale setting is supposed to
>indicate to utilities which character set you're using. So we (rather
>reasonably, I wo
Hi Tom,
> But I don't really agree with the tradeoff that's been made of failing
> when you can't be sure of that.
I don't think nmh should be complicit to you putting an RFC-invalid
email onto the wire; there's enough of them in the world already. :-)
> Especially since, if you think you know
On Mon, 17 Oct 2016 14:35:57 -0400, Tom Lane said:
> Maybe we could just leave off the character set spec if it turns out to
> be definitely wrong?
Non-starter. What position does that leave the recipient's MUA in?
pgpbZrhJaGISp.pgp
Description: PGP signature
__
Hi Ken,
> I just have a hard time adding a switch to send (or really, any nmh
> utility) when there's already OS-supported mechanism for overriding
> the locale for individual commands by changing the environment
> variable.
I'm surprised whatnow(1) hasn't grown the ability to prefix the command
Hi Ken,
> > (3) assume charset=utf-8 (maybe allow this to be overridden in
> > profile)
>
> We already do (1) and (2). (3) is the problem. Other people who have
> thoughts on this topic are free to weigh in. Personally, I believe
> that if you're doing LANG=C, you shouldn't be dealing with any
>The problem I've had with it in the past is that in a situation where *no*
>mail can be sent, you don't get a notification back. Not much surprise
>there, and I've found that the error message does get left behind in
>a file in the drafts folder. But this mhbuild failure neither sends
>warning m
Ken Hornstein writes:
>> Personally I'd love it if send did something like:
>> (1) if text is entirely 7-bit: specify charset=us-ascii
>> (2) if environment specifies a non-ascii character set, use that
>> (3) assume charset=utf-8 (maybe allow this to be overridden in profile)
> We already do (1)
>Personally I'd love it if send did something like:
>
>(1) if text is entirely 7-bit: specify charset=us-ascii
>
>(2) if environment specifies a non-ascii character set, use that
>
>(3) assume charset=utf-8 (maybe allow this to be overridden in profile)
We already do (1) and (2). (3) is the probl
Laura Creighton writes:
> Since us-ascii is a perfect subset of utf-8, is there any reason that nmh
> couldn't take a look at the locale, and if it is us-ascii just use uft-8?
All modern character sets are supersets of us-ascii, so that argument
doesn't really get us far :-(.
Personally I'd love
>Since us-ascii is a perfect subset of utf-8, is there any reason that nmh
>couldn't take a look at the locale, and if it is us-ascii just use uft-8?
Well ... us-ascii is ALSO a perfect subset of iso-8859-1. Or a whole
lot of character sets, actually. Some people would argue those are more
corre
Ken Hornstein writes:
>> Apparently, it's also trying to enforce that by rejecting any
>> non-plain-ASCII content. This is a real pain, mainly because whatever
>> it's doing isn't playing well with exmh: the post simply silently doesn't
>> happen. That's several notches below the already pretty
In a message of Mon, 17 Oct 2016 13:09:35 -0400, Ken Hornstein writes:
>>So I updated to the new RHEL6 package of nmh 1.6 (had been on 1.5).
>>I've found that it now wants to mime-ify outgoing mail and among
>>other things attaches
>> Content-type: text/plain; charset="us-ascii"
>>Apparently,
>So I updated to the new RHEL6 package of nmh 1.6 (had been on 1.5).
>I've found that it now wants to mime-ify outgoing mail and among
>other things attaches
> Content-type: text/plain; charset="us-ascii"
>Apparently, it's also trying to enforce that by rejecting any
>non-plain-ASCII content.
So I updated to the new RHEL6 package of nmh 1.6 (had been on 1.5).
I've found that it now wants to mime-ify outgoing mail and among
other things attaches
Content-type: text/plain; charset="us-ascii"
Apparently, it's also trying to enforce that by rejecting any
non-plain-ASCII content. Thi
64 matches
Mail list logo
