Re: Unbalanced change hooks (part 2)

[Eli Zaretskii]

> Date: Mon, 1 Aug 2016 16:53:23 +0000
> Cc: address@hidden, address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > I'm not suggesting a workaround.  I'm suggesting a fix for a design
> > flaw in CC Mode -- its assumption that before-change-functions and
> > after-change-functions are always invoked in balanced pairs.  CC Mode
> > must not depend on that assumption, because it's false.
> 
> The flaw lies between the Emacs core and the Elisp manual.  The latter
> quite clearly implies that each buffer change is accompanied by a single
> before-change-functions call and a single after-change-functions call.

I don't mind making the manual more explicit on this.  But doing so
won't fix the problem at hand.

> > In practice, we need to make sure that every modification triggers at
> > least one call to before-change-functions and at least one call to
> > after-change-functions.  The numbers of these calls do not have to
> > match.
> 
> And in such calls, what are the parameters BEG, END, and OLD-LEN supposed
> to mean?

That depends on whether the changes are insertions or deletions.  I
thought it was quite clear from the documentation, but if not, we can
spell that out better as well.

> > I had my share of hacking that code [insdel.c] and its callers.  It's
> > impossible to convey everything I learned while doing that in a
> > discussion such as this one.  I say more about this below.  If that's
> > still not enough, you will have to trust me on that.
> 
> OK.  In exchange, I'm asking you to trust me when I say that the sort of
> change you're expecting in CC Mode is impractical - months of work,
> rather than weeks.

I trust you.  I just hope you will find a simpler way of doing that,
after some thought and maybe more discussions.

> > Just don't assume that there will be a c-before-change call for each
> > c-after-change call, that's all.
> 
> What you seem to be saying is that before-change-functions isn't very
> useful.  Since lots of packages use it, you seem to be saying that these
> packages are broken, just as CC Mode is broken.

No, I don't think before-change-functions are useless, and I don't
know about any breakage of packages that use that hook.

> > Specifically, in the case in point, I believe that the "unbalanced"
> > call to c-after-change clearly tells you that text has been deleted,
> > so I think it should be enough for you to do the job of the "missing"
> > c-before-change call as well.
> 
> No.  CC Mode also needs to know what was there before the change.  It
> cannot guess.  I think it's fair to ask you to suggest a way for CC Mode
> to get that deleted buffer section, somehow.

The functions that delete text do call after-change-functions, and
those functions do get this information.  Or maybe I don't understand
what is it that you are asking.

> Here is a list of lisp files which use before-change-functions.
> Currently all of them are broken due to the unreliability of
> before-change-functions:

It depends how they are using this hook.

> Please tell me how CC Mode can get full details of any buffer change,
> then I'll be (reasonably) happy.

You will have to tell much more about your needs, for me to begin
being helpful on that level.  Right now, all I can say is that
after-change-functions provide that information, AFAIK.

> > But before-change-functions _are_ being called in the scenario of the
> > bugs we are discussing.  They just aren't balanced with calls to
> > after-change-functions, that's all.
> 
> No.  In the scenario of bug #24094 there was no call to
> before-change-functions whatsoever.

They were on my system, I saw in GDB signal_before_change being called
from that place in insert-file-contents.  I wonder how come you didn't.

> >       insert_from_buffer (XBUFFER (conversion_buffer),
> >                       same_at_start_charpos, inserted_chars, 0);
> 
> > the before-change-functions are called from insert_from_buffer.  So
> > it's not like the replacement would be missed by the
> > before-change-functions.
> 
> It was missed in the recipe for bug #24094.

How can that be?  insert_from_buffer unconditionally calls
insert_from_buffer_1, which unconditionally calls
prepare_to_modify_buffer, which in turns calls signal_before_change.

> For an atomic user action (namely C-x C-f test.c++ followed by
> typing "yes" to the prompt to reload the file) there was no
> invocation of before-change-functions and one of
> after-change-functions.  This is the bug I am complaining of.

Then I guess we are not talking about the same situation, and some
more digging is in order.  I did reproduce this using the recipe in
those bugs.

> > > In the general case because information gets lost at a change; things
> > > like where the beginning of a statement was, where deleted template
> > > delimiters used to be, what the bounds of a macro or string used to be
> > > (before backslashes were deleted).
> 
> > I'm sure CC Mode is well equipped to recalculate all of these if
> > needed.  It does that when a file is first visited.
> 
> An empty buffer is a fully defined state.  A buffer immediately following
> a deletion is in an undefined state, which requires to know what was
> deleted to make it defined again.

You mean, you cannot just throw away the entire info and recalculate
it anew?  IOW, pretend that you know nothing about this buffer, as if
you have just visited its file?