[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Bug] Issues with format.el: coding system, byte/char confusi on
From: |
Wedler, Christoph |
Subject: |
RE: [Bug] Issues with format.el: coding system, byte/char confusi on |
Date: |
Wed, 9 Apr 2003 20:26:32 +0200 |
Kenichi Handa wrote:
> In article <address@hidden>, "Wedler, Christoph" <address@hidden> writes:
>> I also don't think that the order is correct (if
>> after-insert-file-set-buffer-file-coding-system doesn't do much, it
>> might not matter): since the `buffer-file-coding-system' is used to save
>> the RESULT of the format encode functions, it must be determined BEFORE
>> the format-decode functions have been executed.
> I agree.
>>> Is there any real example where this question arises, or is it
>>> purely hypothetical.
>> I'm not sure since I don't know what
>> `after-insert-file-set-buffer-file-coding-system' does exactly (is it
>> more than eol-type handling?).
> [...] So, as far as format-decode or any other functions in the
> hook don't pay attention to buffer-file-coding-system
X-Symbol's decode function sometimes[1] does pay attention to
`buffer-file-coding-system'. (A hypothetical question became real...)
> or enable-multibyte-characters, we can do the task in any order.
> But, conceptually it should be done before running any other Lisp
> code.
It would be excellent if Emacs could be patched such that
`after-insert-file-set-buffer-file-coding-system' is called directly
from within Finsert_file_contents before calling Qformat_decode (instead
of adding this function to `after-insert-file-functions').
- Christoph
[1] with unique decoding and 8bit char use in the file: then \oe would
not be decoded with a latin9 coding system, but it would be decoded with
a latin1 coding system.