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

[Stefan Monnier]

>> 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.

[ You said "written in any reasonable fashion", so I took it you
  referred to the complexity of the code-writing part, not the runtime
  complexity of the algorithm.  As a matter of fact the above
  suggestion makes the code's writing *more* reasonable since you have
  to handle fewer distinct cases.  ]

Nothing in the above requires scanning from BOB.
And it's reasonable enough (in terms of performance) for all other known
major modes, BTW.

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

As a matter fact, my local CC-mode works just the way I describe above
(via syntax-propertize), and I haven't noticed any slowness so far.

>> 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,

Daniel's wording (and Eli as well, tho maybe slightly less crisply) say
precisely what might come up and does not exclude the technique you use.

You could argue that it lacks an argument of what is *frequent*, which
might influence the design choice, but it in no way restrict the
*possible* designs.

> Nowhere do Daniel or Eli document the reality, that b-c-f and a-c-f
> match very close to 100% of the time.

I think it's OK.  As you and Daniel have argued, it's "natural" for the
reader to presume that b-c-f and a-c-f will always come in perfect pairs
(and that's also what they will quickly find out when testing or
debugging their code), so there's no need to reinforce this natural
assumption.  Instead what the doc needs to focus on is the fact that
this presumption is not always valid and clarify *how* it's invalid.

> 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.

Your CC-mode design is actually correct w.r.t Daniel's wording.
Its good performance is not guaranteed by this wording since it handles
the non-paired case suboptimally but we rarely (if ever) document
performance-related specification anyway, so most code's performance
design is based on experiments rather than on reading the doc.

> I disagree with you totally.

Wonderful!  On the upside, you might like to take a look at the closely
related bug#24340 where you might actually agree with me for once ;-)


        Stefan