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

[Alan Mackenzie]

Hello, Stefan.

On Tue, Aug 30, 2016 at 04:34:46PM -0400, Stefan Monnier wrote:
> > There is software that cannot be written in any reasonable fashion
> > without the technique under discussion.  I suspect, even if I don't know
> > for sure, that CC Mode comes into that category.

> It's trivial to demonstrate that it doesn't:
> - consider any change between START and END to the buffer.
> - you can always decompose it into:
>   (a) delete everything from START to point-max.
>   (b) insert at START (now point-max) the rest of the text.
> - clearly the above deletions and insertions *could* happen, so CC-mode
>   has to handle them and since all changes could be decomposed this way,
>   CC-mode does not *need* to handle any other case.
> - to handle (a) you don't need to know anything from b-c-f.
> - to handle (b) you don't need to know anything from b-c-f.

That's garbage.  Pure garbage.  I said above in any _REASONABLE_
fashion, specifically excluding, in the bit you snipped, scanning from
BOB on every single change.

Even you would start complaining if CC Mode slowed to the slowness it
would have on implementing anything like you're suggesting.

> CQFD

????

> > No, I quite clearly and accurately described the Emacs that does exist:
> > The technique works almost always, but you have to detect and handle
> > exceptions carefully, something that can be easily done.

> Daniel's description gives you the added info necessary to know how to
> detect that situation and what you might want to do about it.

No, Daniel's description, also Eli's description, by any reasonable
reading, completely exclude the use of the technique, using words
like "expect", but using it to mean something different from its
everyday meaning.  I expect b-c-f and a-c-f to match in the same way I
expect to cross the road without being knocked down by a lorry.  It's
the normal event, though not 100% guaranteed.

Nowhere do Daniel or Eli document the reality, that b-c-f and a-c-f
match very close to 100% of the time.  The elisp manual places an upper
limit on what hackers can do with Emacs.  That limit is now lower than
it was before 25.1.  I find that a very sad state of affairs.

> FWIW, I like Daniel's wording.  It is about as precise as we can make it
> without imposing undue burden (IOW I think Emacs's implementation can
> reasonably (and should) obey that description) and I think it gives the
> right intuition.

I disagree with you totally.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).