Re: [Nmh-workers] nmh in near, medium, and far-term

[Ken Hornstein]

(Replying to a bunch of messages ...)

>One of you probably has MM_CHARSET defined and the other doesn't.  'scan'
>(IIRC) doesn't even try to do 2047 quoting if that variable isn't set.

It might be that I am running something newer than 1.3, and Tethys is not.
Anyway, something to look into.  It seems to me that we should start
assuming that you should always do MIME, and always do the stuff that was
previously only turned on my MM_CHARSET.

>I've been getting close to getting peeved enough at exmh's behavior on
>replies to multiparts and QP/base64 encoding to fix it, but it's ugly
>to do it in Tcl if there's no nmh support.  Having said that, I'm not
>sure exactly what the nmh side should look like to make it easiest for
>exmh.

Here's what I'm thinking.  Others may chime in.  First off, let us assume
an UTF-8 locale (the situation gets more complicated if you do not).

- When "repl" is reading the message to compose the reply, the message body
  is decoded; any base64 and/or quoted-printable data is decoded.  No matter
  what the character set, the data is converted to UTF-8.  Or maybe it's
  UTF-16 internally ... anyway, doesn't matter.

- The data is written out as UTF-8 in the reply message.  I guess if you
  have a non-UTF-8 locale, at this point the characters could be converted
  to the target character set.

I think that's 85% of what you need.  If you have a multipart message ...
well, I am thinking of what to do there.  But one step at a time, okay? :-)

>While we have the phrase "nmh libraries" on the table, would it be interesting
>to convert sbr/libmh.a into a .so that can be embedded into other projects?
>I'm thinking that exmh could use that in a few places where it currently has
>to run system() against an nmh binary.  And if uip/scansbr.c was directly
>callable from Tcl, that would fix a number of warts (in particular, a number
>of stale-data issues with the message listing frame - would also make 'rescan'
>and 'pack' a lot faster).

Weeeelll ... I'm open to that, but the only portable way I know of to do
that is to use libtool.  I admit to being a fan of many of the GNU Autotools,
but libtool is the one that still leaves a sour taste in my mouth.  Probably
that has to do with it's horrible misuse in Cyrus SASL.  This has come up
several times though, so perhaps it's worth revisiting.  Valdis, are you
willing to pick up the exmh/Tcl work to use a shared library for libmh?
Actually, if you could crank out another exmh release, that sure would be
awesome.  And if you figured out how to get exmh to use the "fixed" font
with the most recent version of Tk, that would be super-awesome :-)  (As
an aside ... from my brief investigation, it seems that with the changes
to the font handling in Tk you can no longer use any X font that is
semicondensed, and fixing it required looking at the whole Tk font mess).

Many people wrote:
> Not sure if you already have, but I vote to get the maildir patch merged 
> in before tagging 1.4.

Okay, the masses have spoken :-)  I'll gladly do that, as soon as David
Malone sends a patch (we spoke off-line and I hope I made it clear that
while sending something using git-format-patch would be nice, it is
completely not necessary; just get me a patch and I'll get it in
there).

--Ken