<<< Date Index >>>     <<< Thread Index >>>

Re: bug#1876: mutt-1.5.6i: Mutt doesn't handle invalid characters when replying to a mail



 On Sunday, October 3, 2004 at 12:11:08 AM +0200, Vincent Lefèvre wrote:

> On 2004-10-02 21:56:26 +0200, Alain Bench wrote:
>> full ?-masking by setting [...]
> OK.

    You... You agree?!? Et m*rde! I had bet you would have required some
and such default change, if not jail for workarounders... Grrr: I lost
15¤... You owe me a beer! ;-)


    [unknown charset]
>| Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
> with latin-1 characters in the body

    OK: Scenario confirmed. That's the unknown charset case. Mutt does
pass-thru. But there is a nice workar... Oh, sorry, Vincent: Could you
please jump to point B? Yes, now.

 -A) charset-hook ^x-unknown$ windows-1252

    A comfortable workaround to see and quote back accents, suitable in
most cases for latin westerners. Russians may prefer KOI8-R, and so on.
Hookable, unhookable, overridable individually by <edit-type>. Can fail
in rare cases.

 -B) charset-hook ^x-unknown$ us-ascii

    An austere problem detector ?-masking everything without need of the
eat-char recoding. Suitable for most Tetrhex masters. ;-)


> Emacs thought that it was a latin-1 file (and it was quite right), so
> that the body of my reply was encoded in latin-1, though declared as
> utf-8 by Mutt.

    Mutt by design assumes editor is dumb and reads and writes $charset.
Smart editor auto-sensing and recoding just confuses things, and may as
in your example hide during reply typing a real upstream problem with
downstream bad consequences. I'd advice disabling editor's auto-sensing
feature when called from Mutt.


    [bytes 80-9F with label Latin-1]
>> they should be \octalized in editor, as they already are in pager?
> I'd agree on this behavior, or possibly replaced by a question mark.

    Hum... We need a consistent behaviour, with those ones, other
Unicode control chars, and the 00-1F zone. Or a *really* good
justification to make a special case.

    I believe the current behaviour, controls given converted to editor,
is done because those controls may well be interpreted by editor. Or
printed by editor, or masked. Or whatever. After all, an UTF-8 editor
should deal with UTF-8 chars.

    Arguments?


Bye!    Alain.
-- 
« Be liberal in what you accept, and conservative in what you send. »
        Jon Postel / Robustness Principle / RFC 1122