Re: [Nmh-workers] nmh internals: full MIME integration

[Ralph Corderoy]

Hi Ken,

> I guess in this scenario I'm trying to think of what the UTF-8 version
> would get us, rather than just preserving the original header in the
> original character set.  I mean, that's what we do now and it seems to
> work fine.

Mostly, but there's more duff emails coming along from the
base64-everything brigade, even though the RFCs say to use it minimally
IIRC.

    $ scan -forma '%(decode{subject})' .
    ¡Hola world!
    $ repl -editor ed
    454
    /Sub 
    Subject: Re: =?utf-8?B?wqFIb2xhIHdvcmxkIQ==?=

Would be much nicer if it travelled internally as UTF-8 and then popped
into the US-ASCII draft as

    Subject: Re: =?utf-8?B?wqE=?=Hola world!

and into the UTF-8 draft as "Re: ¡Hola world!".

> > Wouldn't readers ask for the headers they wanted.  Either just asking
> > once, e.g. `subject', or for the next one, e.g. `received', from where
> > they left off.  Passing in a special value gets every header, one at a
> > time, in the order they're in the header.
> 
> Well, look at how code like pick is structured now.  Actually, my reading
> of the code is if you're looking at multiple headers in the same message,
> the message gets re-read.

Yes, ltrace suggests

    pick --foo 1 -o --bar 2 .

does

    fopen
        fseek to start
        fgets multiple times
        fseek to start
        fgets multiple times
    fclose

> I just think that reading the message off of disk is the dominant
> factor at work

Only the first time; the headers of my fairly large +inbox cache in RAM
quite easily.

Ah, OK, I was thinking we were after an interface that allowed more
optimal behaviour in the future rather than one that was only satisfying
today's users of the existing interface.

It's you doing the hard graft.  We're just trying to get the most value
from it.  ;-)

Cheers, Ralph.