| 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