[Top][All Lists]

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

Re: Reliable after-change-functions (via: Using incremental parsing in E

From: Yuan Fu
Subject: Re: Reliable after-change-functions (via: Using incremental parsing in Emacs)
Date: Mon, 30 Mar 2020 15:21:10 -0400

> On Mar 30, 2020, at 3:10 PM, Eli Zaretskii <address@hidden> wrote:
>> From: Yuan Fu <address@hidden>
>> Date: Mon, 30 Mar 2020 15:02:58 -0400
>> Cc: Štěpán Němec <address@hidden>,
>> Eli Zaretskii <address@hidden>,
>> emacs-devel <address@hidden>,
>> Andrea Corallo <address@hidden>
>>>> (In short, `dired-readin' binds `inhibit-modification-hooks' to t, so
>>>> the buffer changes caused by populating dired buffers are not noticeable
>>>> in `after-change-functions'.)
>>>> I was wondering if I should report it as a bug, despite the workaround
>>>> not being particularly painful in this case (there's 
>>>> `dired-after-readin-hook').
>>> I think it deserves a bug report, yes.
>>>       Stefan
>> Is it really a bug of dired-mode? Dired-mode probably has a good reason to 
>> bind `inhibit-modification-hooks` to t. And if we provide such feature 
>> (disabling after-change-functions), we should expect people using it. Maybe 
>> there should be a reliable way to be informed of buffer changes (that cannot 
>> be silenced).
> I agree with Stefan: it's a bug.  All dired-readin needs to do is call
> the modification hooks after it's done reading in the directory.  It's
> just an optimization that it inhibits the hooks while it runs: read
> the comments there and you will see why it is done.
> IMO, inhibit-modification-hooks is for when some code makes a
> temporary change, or a change that no one is supposed to care about,
> like changing faces.  Any other case is a bug.

I see. Then I suggest mentioning it (when you should use the variable) in the 
documentation of `inhibit-modification-hooks'.


reply via email to

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