[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What does `undecided' do for encoding text?
From: |
Eli Zaretskii |
Subject: |
Re: What does `undecided' do for encoding text? |
Date: |
Tue, 10 Feb 2009 11:22:15 +0200 |
> From: Kenichi Handa <address@hidden>
> CC: address@hidden
> Date: Tue, 10 Feb 2009 16:01:10 +0900
>
> In article <address@hidden>, Eli Zaretskii <address@hidden> writes:
>
> > It looks like `undecided' works the same as `raw-text' for encoding
> > text. Is that true in general?
>
> Yes. More exactly, it is the same as `raw-text-unix'.
Thanks.
> > I think this should be reflected in the ELisp manual.
>
> I don't think so because it is just a fallback behavior, and
> Elisp programmer should avoid specifying `undecided' on
> encoding.
This may have nothing to do with what the programmer did. My use case
was in Rmail: if the original message had non-ASCII text encoded with
QP or B64, Rmail would (correctly) return `undecided' when it detects
the message encoding. Suppose you then edit the message and add
non-ASCII characters as raw bytes, e.g. by base64-decode-region, and
type "C-c C-c". rmail-cease-edit now needs to encode the text and put
it back into the mbox buffer, and the immediate choice it has for the
pertinent coding-system is to use buffer-file-coding-system of the
buffer where the message was edited. But the value of
buffer-file-coding-system in that buffer is `undecided'...
If you say that using `undecided' in encoding is ``considered
harmful'', we should at least say that in the ELisp manual. Although
in the use case I described `undecided' did exactly what's right, and
the only other correct choice is `raw-text'.