Re: insert-file-contents and format-decode

[martin rudalics]

>     We have a plan for dealing with functions called by `format-decode'.  We
>     do not have a plan yet for dealing with `after-insert-file-functions'.
>     Shall we treat functions there the same way we treat functions called by
>     `format-decode'?
>
> If it's good for one, it's probably good for the other.  Consistency
> between the two features is also good.
>
> Do you see any reason NOT to do so?

We could introduce one: Keep `format-decode' for practical use and
`after-insert-file-functions' for applications that want to fine-tune
every single step of the decoding process.

>     When I insert the contents of a file with `visit-flag' nil the buffer
>     should be reasonably narrowed to work only on the inserted text as in
>     `decode-coding-inserted-region'.  Currently, neither `format-alist' nor
>     `after-insert-file-functions' handling provides such a service.  The
>     functions there are supposed to do the narrowing themselves.
>
> Perhaps it would be convenient to narrow around the call to
> the `after-insert-file-functions'.  This would not contradict the
> established calling convention.
>
> If we want to narrow around format conversion functions, the place
> to do that is inside format.el.

I already changed my mind: I now think instead that `format-decode' and
`after-insert-file-functions' _should_ be able to detect whether the
insertion is done at the beginning of the current buffer or any other
position (simply by comparing the `begin' argument with `point-min'
wthout any need to widen the buffer).

The only clean way to handle this would be using a temporary buffer for
decoding.