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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Tue, 30 Aug 2016 09:23:51 -0700
> 
> > You are setting the bar impossibly high by expecting that.
> 
> To be fair, according to Alan, XEmacs meets this impossibly high bar. 

I disagree with Alan (having looked at XEmacs' sources).

> (And its insdel is considerably simpler.)

That wasn't my impression.  Beyond some stuff that is missing simply
because XEmacs doesn't support it, the code is the same, except that
they also have a separate "multi-change" hook called around changes
that are done piecemeal, in addition to the hooks we have.  IOW, it's
a different model, and not necessarily a solution that we are looking
for.

Of course, I didn't read their sources too seriously, so maybe I
missed something.

> In today's world, do we really *need* the optimizations that complicate 
> change region tracking? Might these things just be just as unnecessary 
> as the old code that used to special-case self-insert-command in the 
> event loop?

I'm not sure which optimizations are you talking about, so it's hard
to answer that question.  I can tell that decoding a large file when
we visit it takes a significant amount of time, even with today's
machines.  So at least some optimizations we have, like reading into
the gap, are probably still justified.

Of course, removing/simplifying optimizations in these internals would
also need good test coverage, to make sure we don't introduce bugs
while at that ;-)