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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Davis Herring <herring@lanl.gov>
> Date: Thu, 1 Sep 2016 15:25:01 -0600
> 
> > This is a naïve interpretation of what a "change" means and entails.
> > In reality, some changes are done with a single call to an insdel
> > function, while others need multiple calls that delete and insert text
> > piecemeal.  Thus the need to call the hooks before and after each
> > insdel call only sometimes.
> 
> Indeed, no one knows what we mean by "change".  To make progress, we 
> must introduce a formal definition for it

I envision that to be a very hard job, given the complexity of some
changes and the fact that at least some of them are not considered
"changes" for this purpose (see past discussions for the details).

Moreover, doing so was never the Emacs way.  Emacs always tries to do
things the naturally expected way, so that these issues don't arise.
If we need to go into such fine details and argue about formal
definitions of a "buffer change", that is a clear sign that something
is wrong and needs to be fixed, in a way that makes the "natural"
definition be implicitly correct, because the effect is as expected by
Lisp programmers.

Therefore, I think that spending any effort on making the manual text
more formally correct will be a wasted effort.  As long as the
implementation remains as it is now, the problem with its accurate
description in the manual will persist, and no small patches to the
code will resolve it completely.

> I therefore propose approach #3 as the minimal change to the current 
> implementation that provides a behavioral guarantee worth documenting. 

I don't think this issue can be attacked using only abstract
high-level considerations and resolved by solutions that are logically
complete, but may not be helpful in practice.

Instead, the use cases we want to support, both wrt the implementation
of complex changes we have in Emacs and wrt the users of these hooks,
should be collected and analyzed.  Then the best approach that
accommodates these needs (including perhaps any future needs we can
envision) should be designed and implemented.  My gut feeling is that
the correct model which will emerge from this will be very different
from what we have now.

Thanks.