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

[Alan Mackenzie]

Hello, Stefan.

On Wed, Aug 10, 2016 at 03:50:06PM -0400, Stefan Monnier wrote:
> >   Do @emph{not} expect the before-change hooks and the after-change
> >   hooks be called in balanced pairs around each buffer change.  Also
> >   don't expect the before-change hooks to be called for every chunk of
> >   text Emacs is about to delete.  These hooks are provided on the
> >   assumption that Lisp programs will use either before- or the
> >   after-change hooks, but not both, and the boundaries of the region
> >   where the changes happen might include more than just the actual
> >   changed text, or even lump together several changes done piecemeal.

> That looks OK, thank you.  It does make it sound like sometimes b-c-f
> won't be called at all,

That is the current status, yes.  In the bug which gave rise to this
discussion, bug #24094, a certain change did not call b-c-f at all.

> whereas AFAIU it is *always* called before a change, tho maybe "too
> early" (i.e. announcing several changes at the same time), but I think
> it's good enough for now.

> > One can (indeed, often MUST) expect b-c-f and a-c-f to work in pairs,

> No.  I know you *want* to expect it, but that assumption has not been
> true for many years and we don't want to impose it on ourselves.

The Elisp manual, up until yesterday, documented implicitly that b-c-f
and a-c-f were paired.  It has also been true, up to 99.99..%, otherwise
CC Mode wouldn't work at all.

> Furthermore there is no evidence that you "MUST".
> I gave various examples of ways you can live with only a-c-f.

Vague hand-waving is what I remember.

> > Editing text involves deletions and insertions.

> It also involves replacements.

> > Deletions can be known only in before-change-functions, insertions
> > only in after-change-functions.

> Not at all.  Deletions are definitely announced to a-c-f.

You know full well what I mean.  By the time you get to a-c-f the
deletion as announced is a hollowed out husk, all its details except for
its position and size having been lost.

What you and Eli are asserting is that one NEVER IN ANY CIRCUMSTANCES
needs to know the full details of a buffer modification, and no program
now or in the future ever will.  The burden of proof has not been met.
With the recent change in documentation, Emacs 25.1 has become a less
powerful programming system, one in which these details cannot be
determined.

> > CC Mode absolutely requires to know both deletions and insertions for
> > its proper functioning.  Nobody has yet demonstrated that it can work
> > properly knowing only insertions, despite Stefan loudly and repeatedly
> > proclaiming it can.

> All major modes using syntax-propertize demonstrate it.  C++ has its
> share of syntactic quirks, but none that are fundamentally very
> different from what we find in other languages such as Perl.

If you want to try and construct a CC Mode which disregards deletions,
you are welcome.  I won't stand in your way.  But I will try and break
it.

[ .... ]

> >   enabling state to be determined in a before-change function and used
> >   in an after-change function.

> That's exactly what I want to strongly discourage.  Based on my
> experience with CC-mode, I'd even say that it's just a bad design, even
> if the hooks were always called in pairs.  I don't know nor care about
> how we ended up with such a design, ....

You really ought to: those who are ignorant of history are doomed to
repeat it.

> .... and I understand that you might prefer to try and live with it
> than to go back and rethink it, but it's still a bad design (nor is it
> the only bad design we have in Emacs, of course).

You've been libelling my design for longer than I can remember.  It's
different from how you'd try to do it, that's all.  It's a good design,
and it works well.  It's a straightforward and obvious distillation of
requirements and Emacs's documented features.  You recently admitted
you'd never tried to build anything that way, so you're just saying "my
way is better".

As I say, if you really think your way is better, hack it, and we can
compare.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).