Re: insert-file-contents and format-decode

[Richard Stallman]

    `format-decode' is similar to character decoding and eol conversion.

They are similar in their conceptual roles, I agree.

                                                                          We
    don't run `after-change-functions' for decoding characters or converting
    line ends.

We do, when they operate on text already in the buffer, as for
M-x decode-coding-region.

However, when `insert-file-contents' does decoding, it does not run
the `after-change-functions' for that.  Instead it lumps the decoding
together with the reading of the file, and runs the
`after-change-functions' just once, for the insertion of the decoded
text.

It would be ok to do the same thing for format decoding, but that is
not what the current code does.  What it does now is this" first it
runs the `after-change-functions' for the decoding, then it runs the
`after-change-functions' for the insertion of the text resulting from
decoding.

That is clearly a bug.

Is your suggestion to fix this by disabling the modification hooks in
Finsert_file_contents around the call to `format-decode'?  That sounds
like a good idea.

     > 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.

Maybe we should, for `after-insert-file-functions'.  Are there
any cases where those functions do inhibit these?

    An aside: `format-decode' has

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

Maybe that is a bug.  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.

Would you like to try this?