RE: [Bug] Issues with format.el: coding system, byte/char confusi on

["Wedler, Christoph" <christoph.wedler@sap.com>]

Kenichi Handa wrote:

 > In article <67B8CED503F3D511BB9F0008C75DAD6605485571@dewdfx17>, "Wedler, Christoph" <christoph.wedler@sap.com> 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.