Re: Lisp primitives and their calling of the change hooks

[Stefan Monnier]

>> Implementation flexibility, of course (which apparently Eli doesn't
>> want to take advantage of very much).
> What flexibility?

"Implementation flexibility" here means flexibility in
implementing primitives.

E.g. not needing to care about "what happens if I get an error after
I called b-c-f but before I actually modify the buffer"?

>> > and in what conditions would those advantages outweigh the known
>> > disadvantages in allowing unbalanced change hooks?
>> What known disadvantages?
> That b-c-f and a-c-f can't work smoothly together in partnership.

They can still work smoothly in partnership.

The assumptions and guarantees needed are slightly different but I still
haven't seen any example where the difference leads to a more complex
implementation of the b-c-f and a-c-f hooks.

> Instead, at the moment, to be rigorous, code must use non-nice artifices
> to cope with the rare occurences of unbalanced change hook calls.  You
> know CC Mode does this.  An example, in C++ Mode, is where the b-c-f
> function removes balanced paren syntax-table text properties from
> template delimiters when half of a pair is about to be deleted.  This
> mechanism expects a matching a-c-f so as to put them back where needed.

Yes, cc-mode has trouble because it was designed based on
balanced behavior.

If you had designed it based on correct assumptions you wouldn't have
removed the properties in the before part.  You'd instead have made this
removal lazily (i.e. in b-c-f just collect the info from the about-to-be
modified region (could be as simple as stashing (buffer-substring beg
end) or some buffer position indicating which template delimiters will need
to be re-analyzed), and then use it in the a-c-f).

I don't see any reason why the resulting system would be noticeably
more complex or less efficient.

Going from one to the other is extra work, but that's not the
fault of the system.

> Indeed, rigorous pairing of b-c-f and a-c-f would increase the
> flexibility of programs using them, not decrease it.

Yes, by definition.  But I still haven't seen any example where the
difference actually matters.


        Stefan