Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]

[Daniel Colascione <dancol@dancol.org>]

On 08/29/2016 10:01 AM, Eli Zaretskii wrote:
>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Mon, 29 Aug 2016 09:26:38 -0700
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>
>>> We are talking about code that runs virtually
>>> unchanged for many years.  Making significant changes in it needs a
>>> good reason.  When such good reasons emerge, we can discuss whether
>>> they justify the risks.  For now, the reasons presented do not.
>>
>> What criteria are you using to determine whether a bug is sufficiently
>> serious to fix? What would convince you that a change in this behavior
>> is warranted?
>
> I described up-thread what would constitute a good enough reason for
> me to consider such changes for admission.  Here's the list again:
>
>   . a bug that affects (i.e. breaks) the core code itself (e.g., see
>     bug#5131 fixed in 00b6647 as a recent example related to insdel.c)
>   . a problem that affects several Lisp packages for which there's no
>     reasonably practical workaround/fix as part of the package itself
>   . refactoring done as part of introducing a significant new feature

We have two separate bugs here. In order of severity:

1) Something b-c-f is not called _at_ _all_ before certain changes
2) Sometimes b-c-f is called once, then a-c-f is called multiple times, 
because internally, changes are split into several chunks, each of which 
gets its own a-c-f call

I can understand #2 being wontfix, but can you reconsider fixing #1? #1 
breaks the entire b-c-f model --- "hey, I'm about to modify the buffer, 
so throw away caches" ---- and can lead to anything with a cache flush 
in b-c-f (like syntax-ppss) not properly discarding out-of-date buffer 
information.

>
> Please note that not every change/bugfix is required to pass such
> scrutiny, only changes in code that is very central to Emacs
> operation.  I think manipulation of buffer text, display engine, basic
> file I/O, and encoding/decoding stuff are such areas.  Changes that
> affect some aspects of more local, specialized behavior are normally
> less risky.  IOW, there's still a judgment call needed in each case,
> so that the above is applicable to as few changes as possible.
>
>