Re: mhfixmsg character set conversion

[Steven Winikoff]

>>    1) What's the best replacement for elinks?
>
>mhn.defaults.sh looks for text/html helpers in this order:
>    1. w3m
>    2. lynx
>    3. elinks
>
>I don't know if one is necessarily "better" than another.

I've tried all of w3m, elinks, links and lynx at different times, and I'd
settled on elinks at the one that reproduced the HTML most accurately
(subject to the obvious limitations of a text terminal, but you know what I
mean).

I no longer remember what the differences were, but they probably had to do
with HTML <table> constructions.

Anyhow, accuracy/faithfulness to the original is what I meant by "best".

I've settled on w3m for now, subject to further testing.


>If you have suggestions on how to improve the arguments that mhn.defaults.sh
>uses for elinks, please let us know.

If I can make elinks do what I need, I certainly will; however, for the
moment at least it looks like I'm unable to accomplish that, which is why
I've switched to w3m for the moment.  For the record, my w3m invocation
looks like this:

   w3m -I ${cset} -T text/html -dump -s -o display_link_number=1 \
       -o color=1 -graph ${html} | sed 's/^   //;s/[   ]*$//'

...where ${cset} is the character set assigned in .mh_profile, and ${html}
contains the HTML code to be rendered.


>>    2) Should I replace my 1.7.1 installation by the version I just built?
>>       Basically I'm asking what benefits the current snapshot has over
>>       1.7.1,
>
>See docs/pending-release-notes.

Thanks, I will.


>>       and how far away the next numbered release might be.
>
>Unknown.  Ken appears to be busy.  One of us here could push it out.  It's
>been almost 4 years so I think that would be a good idea.  Perhaps after
>things here settle down a bit.

Please let me clarify that I wasn't trying to rush anything or put pressure
on anyone; I was just asking for an estimate, because that would help me
decide whether or not to wait for it.


>>    3) How can I guarantee that messages will be saved with quoted-printable
>>       or base64 parts decoded, without patching mhfixmsg to deal with
>>       messages in which the decoded text would be more than 998 characters
>>       long?
>
>I don't know your reason for patching mhfixmsg.

At the time I didn't understand how or why to use -decodetext binary, so
the patch was the only way I could find to guarantee that text/html parts
would be decoded, no matter how badly formatted the HTML is (and by then
I'd already discovered just how bad that can be :-/).


>IIRC, you were using -decodetext 8bit; binary instead of 8bit might help.

Yes, I understand that now, though I still have the question you answered
below about the practical difference between binary and 8bit.


>>          - Why wasn't the text/html part converted to utf-8?
>
>mhfixmsg only converts the character set of text/plain.  That was a
>design decision.  Other subtypes can be extracted with mhstore and run
>through iconv.  If there's a use for converting them in place in
>mhfixmsg, it wouldn't be difficult but I'm not sure how useful it
>would be.

It would be useful for me, because some messages don't have a text/plain
part, and my main motivation for storing the decoded text is the ability
to search it with grep and mairix.

...but I can modify my shell script to run mhstore and iconv as you
suggest, so for me having a modified mhfixmsg would be nice but not
actually necessary.


>>          - Regardless of the answer to the previous question, after a
>>            message has been refiled (and assuming I'm not planning to
>>            resend it to anyone), is there a practical difference between
>>            binary and 8bit encoding?
>
>"Note that -decodetext binary can produce messages that are not compliant
>with RFC 5322, §2.1.1."

Understood (you made it clear when I first asked about the 998-character
limit that my patch has the same effect), but I don't care; I'm storing
messages in case I need to reread them later, and if I ever need to resend
something that wouldn't be compliant (and so far I can't remember that ever
happening), I'd be sending the converted plain text anyway.


>Is it a proper MIME message (does mhfixmsg return with a non-zero exit
>status)?  If so, can you send it to me off-line?

It's the same message I already sent to you, that I've been using as a test
case all through this discussion.  I just checked, and mhfixmsg returns a
zero exit status for it.

     - Steven
-- 
___________________________________________________________________________
Steven Winikoff      |
Montreal, QC, Canada | "It is never too late to be what you might
smw@smwonline.ca     |  have been."
http://smwonline.ca  |                         - George Eliot