Date: Tue, 28 Oct 2014 09:28:39 +0000
From: Jon Fairbairn
<jon(_dot_)fairbairn(_at_)cl(_dot_)cam(_dot_)ac(_dot_)uk>
Message-ID: <wfy4s01r20.fsf@calligramme.charmers>
| A more convoluted (but more correct) strategy would be for the
| user to set up a separate config direcotory $CFG in which
| unicode has been set as the default encoding and then have mh
| pass --user-data-dir=$CFG when calling chrome.
That might be more correct than the earlier suggested hack, but certainly
is not the right way - you cannot possibly expect the user to be able to
guess what charsets arriving messages will happen to contain, so they can
have pre-setup browser configs containing everything that might appear.
If the browser vendors cannot be convinced of the utility of providing a
command line switch to set the default char set (which can be passed through
to the actual browser that displays the page however they like) then the
only alternative to me would seem to be to wrap the html from the message in
enough extra glue to expressly define the char set to use.
I did notice that html decoding of that message (and I suspect, most
messages) is working only because the browsers assume anything passed to
them will be html - it had none of the normal html lead in noise - not
even <html>.
Of course, a rational alternative is to simply ignore the html, and read
the text version - it was every bit as good, and (in the case in question)
was all simple untarnished ascii... (that's what I do reading e-mail with
either exmh, or from the command line, with vi).
kre
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers