Re: The current state of the comment-cache branch

[Alan Mackenzie]

Hello, Stephan.

On Fri, Dec 23, 2016 at 08:32:42PM -0500, Stefan Monnier wrote:
> > I would like the comment-cache code to be merged into master soon.

> This message is probably redundant, but just to make it clear:

> I'm opposed to this change as it is because I find its cost/benefit
> tradeoff to be poor.  I don't think solving some rare pathological case
> of (forward-comment -1) deserves this complexity.

The prime benefit is that open parens in column 0 inside comments
entirely cease to be an issue.  They are far from rare pathological
cases.  They have turned up continually in bug reports for many years,
including in Paul's bug #22884, where the cause of a 10s delay in a
simple edit was such a paren in column 0.

> I think we'd be better off with either:

> - a simpler change, to reduce the cost part of the tradeoff (such as the
>   one I suggested, using syntax-ppss; such a change might make extra
>   demands on syntax-ppss which will require further "refinement" to
>   syntax-ppss, but these refinements are needed in any case, so are not
>   an argument against that change, but only an argument to delay the
>   change).

This would involve a substantial change to syntax-ppss.  The way it is
at the moment, a use of syntax-ppss involves scanning forward over, on
average, 10,000 characters.  This would dominate the time taken to move
backwards over a small comment, slowing it down by 2 orders of
magnitude.  The time taken by comment-cache to do the same movement is
low, and essentially independent of the size of the comment.

> - a more thorough change, to improve the benefit (i.e. make your
>   "comment-cache" able to provide the same kind of information that we
>   currently get via syntax-ppss, so it can supersede syntax-ppss).

I can't imagine how that could work.  comment-cache, as you know, keeps
the "literal state" of all positions in text properties.  Were the
entire parse state to be encoded thus, the number of conses involved
would increase dramatically, along with the overhead on the text
property system.

parse-partial-sexp currently has a facility to stop at the start or end
of any string or comment.  This is used in comment-cache to write the
text properties.  There is no corresponding facility to stop after _any_
change in parse state.  Maybe this could be written, but the
benefit/cost ratio might be low.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).