Re: insert-file-contents and format-decode

[martin rudalics <rudalics@gmx.at>]

 >     (1) The `format-decode' ("round-trip" as the new Elisp manual entry
 >     calls them) based functions are Lisp functions, may change the buffer,
 >     and may call the after-change functions for what they do.  They precede,
 >     within `insert-file-contents', the after-change-functions call.
 >
 > That sounds like a bug to me.  I guess signal_after_change
 > should be done before `format-decode'.
 >
 > Does anyone disagree?

`format-decode' is similar to character decoding and eol conversion.  We
don't run `after-change-functions' for decoding characters or converting
line ends.

 > Can you test such a change?

It would have to be tested against the `after-change-functions' of many
major and minor modes (which holds for testing the present behavior as
well).

 >     (2) Calling `after-change-functions' from within `format-decode' or
 >     `after-insert-file-functions' seems to me highly risky.  Personally, I'd
 >     never trust any of them if they don't use `inhibit-modification-hooks'.
 >
 > I won't say you are wrong, but I don't see why that would be so.
 > Can you explain?

People who write after-change functions usually don't think in terms of
raw text.  They think in terms of fully decoded buffer text.

 >     (3) Not calling `after-change-functions' after performing all functions
 >     in `after-insert-file-functions' may mean, for example, not executing
 >     `font-lock-after-change-function' after inserting the contents of some
 >     file in the current buffer.
 >
 > No, because if `after-insert-file-functions' change the buffer,
 > the primitives they use will themselves call signal_after_change.

Then we must tell people to not inhibit such hooks while running the
primitives.

An aside: `format-decode' has

   (let ((mod (buffer-modified-p))
         ...
	  ;; Don't record undo information for the decoding.
         ...
       (set-buffer-modified-p mod))

hence it does not change the buffer-modified state.  It's somehow
unnatural to run `after-change-functions' and keep the buffer-modified
state unchanged at the same time.  The comment about not recording undo
information suggests that someone has been considering (but not
implementing) this.  If it's implemented it would probably have to be
done as in `after-insert-file-set-coding' (very tedious).  And we'd have
to decide and document how `after-insert-file-functions' shall handle
this.  If it's not implemented, `undo' may reveal the raw file contents
which seems worse.