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.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers