Re: Bug reported regarding Unicode handling in email address

[Ken Hornstein]

>  | to automatically run "mhbuild" on all drafts because nmh users had
>
>I recall that happening I think - I suspect it never was an issue for
>me, as I have (still have, and have had for a LONG time) the -mime
>switch for send (and push) in mh profile.

Ah, I had to look that up.

I don't think the -mime switch does what you think it does.  What it
does is IF you are sending a Bcc to someone, it will encapsulate the
Bcc as a multipart/digest.  It doesn't do anything else and definitely
does NOT automatically run mhbuild/mhn.

>I need to ponder all this more (05:xx in the morning isn't the best
>time for clear thinking - and I am *not* an early riser!) but I think
>this might be exactly what I don't want.  I don't want to manually (or
>via calling mhbuild manually, via one path or another) have a fully
>constructed MIME message in the draft (or not usually), what I want is
>to be able to provide explicit info about things I know to be true about
>the draft, and have nmh (mhbuild or whatever) use that info rather than
>guessing, which most probably just means the content-type field.

Right, well ... we don't QUITE have that now the way you want it.  But
you can get close.

Probably the best way to do that is using mhbuild directives.  That is,
you can today do stuff like:

#<text/plain; charset=utf-8
[... utf-8 text here ...]
#<text/plain; charset=iso-8859-1
[... iso-8859-1 text here ...]
#<text/html; charset=utf-8
[... HTML text here ...]

You can also intermix this with Attach: headers.  But mhbuild can't
modify an already-built MIME message.  Whether or not it should,
well ... it would be a lot of code.  You should be able to generate
any kind of MIME structure you want via mhbuild directives.

>I do that, not so much because I want to, but because that's what
>happens when no LC_* env variables (nor LANG) exist at all.  That's me.
>I believe you understand that locales aren't exactly first class objects
>in NetBSD...  (Or not yet anyway).

Well, I guess I don't know what you mean by "first class objects"!.
I was under the impression locale support exists on NetBSD.

>The usual problem I encounter is people who insist on using "fancy"
>quote characters, rather than the ascii ones, in an otherwise ascii
>message.  When I include that as a quote in my reply, the UTF-8
>encodings of those things appear in the draft - with my C locale.

Right, I mean ... this is kind of our (nmh's) fault, and kind of your
fault.

We have some kind of bolt-on tools included in contrib (replyfilter)
that help with this.  The general idea is in your reply draft you're
supposed to convert any text you want to include in your reply to
your native locale; it's your fault you don't do this.  It's nmh's fault
that we don't really do it either, or we don't make it easy.

>All something of a mess (but if "repl" noticed it was including the body
>of the message in the reply - and clearly it does - and could then look
>at the Content-type of that message (or what that was converted into)
>and add that to the draft (to be used as above) I suspect there would be
>far less problems.

That approach seems a bit fraught, especially when dealing with multibyte
character sets like UTF-8.  At least the common iterations of 'vi' know
how to deal with UTF-8, but if you get sent a message using iso8859-1
but your editor is expecting UTF-8, your approach would potentially
end up with ISO8859-1 and UTF-8 in the same message which wouldn't work
at all.  I HAVE seen replied-to messages like that, sadly.

--Ken