emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] emacs-26 671dc5a: Fix calls to buffer modification hoo


From: Stefan Monnier
Subject: Re: [Emacs-diffs] emacs-26 671dc5a: Fix calls to buffer modification hooks from replace-buffer-contents
Date: Sat, 21 Jul 2018 16:46:47 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> >> I don't understand enough of the code to have an opinion on it, but the
>> >> comments describe a behavior which would be wrong: both before-c-f and
>> >> after-c-f- need to be run for any buffer change, even if it's only an
>> >> insertion or only a deletion.
>> > What if there's no change at all, i.e. no deletions and no insertions?
>> Then you can either run neither of the hooks, or both.
> How can we determine whether to run neither or not?

You can roll a dice.

> I can easily run both, but is that TRT?  It was you who requested not
> to run the hooks on a range that is larger than we can determine by
> looking at the results of compareseq.

Running both would not be a bug: it would be sub-optimal but not
incorrect (just like your original choice of running the hooks over the
whole buffer).
If it's easy to do the better choice is to do nothing.

> The recipe describes a case where "foo" is replaced by "foo", and the
> code in compareseq tells us not to change anything.  There are no
> deletions and no insertions.  Do we call the modification hooks in
> this case?

If we can refrain from calling them, it's better to do that.

But this thread is not about the case described in the bug-report, where
there's been no change.

It's about the text in the two comments you introduced: they say (or at
least can be interpreted to say) that the code may run only one of the
two hooks in some cases.  If that text is a correct description of the
code, it means we have a bug in the code, and if not it means those
comments should be improved.


        Stefan



reply via email to

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