[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: insert-file-contents and format-decode

From: martin rudalics
Subject: Re: insert-file-contents and format-decode
Date: Sat, 30 Jun 2007 13:32:55 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

>     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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]