Re: insert-file-contents and format-decode

[martin rudalics <rudalics@gmx.at>]

 > Is your suggestion to fix this by disabling the modification hooks in
 > Finsert_file_contents around the call to `format-decode'?

Either in Finsert_file_contents or within `format-decode'.

I'm not sure what to do with `after-insert-file-functions' though.  The
current documentation suggests that these are handled the same way as
the `format-decode' based functions.  If you want to keep the current
behavior for them, this should be documented throughly.  That means, the
documentation should say that functions in `after-insert-file-functions'
have to take care of narrowing, `buffer-undo-list', after-change hooks,
and the like.

 > If you run format-decode not as part of
 > insertion, I think it should record undo info.  When it is called from
 > `insert-file-contents', that command should arrange just one undo
 > entry, for the inserted file contents as finally decoded.

In general `format-decode' should be run only by `insert-file-contents'
and functions like `format-decode-region' and `format-decode-buffer',
that is, functions in format.el.

 > Would you like to try this?

We'd have to distinguish the calls of `format-decode' by

(1) `insert-file-contents' with `visit-flag' t

(2) `insert-file-contents' with `visit-flag' nil

(3) functions within format.el (and maybe other functions)

for example, by abusing the visit-flag which could assume the value t
for (1), the symbol `insert-file-contents-non-visit' for (2), and nil
otherwise.  Then I'd simply steal the corresponding stuff from
`decode-coding-inserted-region' and bind `inhibit-read-only',
`inhibit-point-motion-hooks', and `inhibit-modification-hooks' to t
(unless that's already done in Finsert_file_contents).