Re: Bug #25608 and the comment-cache branch

[Alan Mackenzie]

Hello, Stefan.

On Sat, Feb 11, 2017 at 19:55:46 -0500, Stefan Monnier wrote:
> > In the current situation I think that both Stefan and Dmitry have an
> > emotional attachment to syntax-ppss despite its manifest flaws, and it

> Of course, I have an emotional attachment to syntax-ppss, since I wrote
> it and used it all over the place.  And of course you have an emotional
> attachment to comment-cache since you wrote it.

I also have an attachment to it because it works, and would save me
demoralizing work debugging bugs caused by open parens in column zero in
comments.

> But using words like "flaw" to describe a simple shortcoming of the
> current implementation, is really not helping.  I hope I never wrote
> something about your comment-cache that was similarly aimed at just
> putting it down.

Bug #22983 is a flaw.  It has been open for nearly a year, yet for some
reason isn't being fixed.  Also the cache invalidation in syntax-ppss is
less than rigorous.  For example, the cache isn't invalidated when
syntax-table text properties are applied or removed.

> BTW, your comment-cache doesn't fix that "flaw" and hence won't help any
> of those users of syntax-ppss which can't be changed to use your
> comment-cache.

That's incoherent.  comment-cache was never intended to help those other
uses, though it appears it could do so for most of them.  That
particular flaw we're talking about doesn't appear in comment cache, so
there's nothing to fix there.

> Which is why I said many months ago that it'd be fine to use something
> like your comment-cache *if* you extend it to provide the
> functionality of syntax-ppss.

Can't be done, as I keep telling you.  comment-cache is solely for
handling literals.

> But that's also why I think this whole discussion is pointless: we first
> need to focus on that "flaw" which comes to the problems of narrowing
> and whether tools like syntax-ppss, comment-cache, font-lock, etc... can
> and should widen and if so when and up to where.

Maybe sometime.  In the meantime, the bug with open parens in column
zero in comments should be fixed.

The question of "widening" is not difficult.  Narrowing a buffer should
not change the syntax of the characters in it.  Doing so leads to
inconsistencies.

If I understand correctly, the problem is that multiple-major-mode modes
are trying to use narrowing to get a null syntactic context.  They are
trying this because we don't provide anything better.  We should provide
something better.  I suggested such a something last spring ("islands").
If each buffer position has an unambiguous syntactic context the
question of "widening" simply evaporates.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).