Re: Bug #25608 and the comment-cache branch

[Stefan Monnier]

> Naturally, we'd need to save more information to be able to do
> that. E.g. propertize the end of a complex comment with the position of its
> beginning. Since the first time we go through a buffer is in the forward
> direction, getting that info would be inexpensive.

Actually, back_comment may very well parse backward "the first time",
since it doesn't use any cache (currently).

>> Maybe.  Obviously, my syntax-ppss hammer makes me think that such
>> alternate solutions aren't needed: syntax-ppss solves this case without
>> having to try and come out with a clever way to detect which comments
>> are tricky nor how to mark them.
> The alternative tweak I had in mind would be applied somewhere around
> syntax-propertize.

But you still have to decide what info to save and when.  I.e. there's
a design problem, with non-trivial tradeoffs.
Using syntax-ppss saves me the trouble.

> Another thing to consider is that we would probably want to fontify the
> contents of all subregions normally, even when inside comments belonging to
> the outer mode. So the primitives used in
> font-lock-fontify-syntactically-region would need to be able to stop at
> those boundaries instead of automatically skipping over.

That's right.

> Just having those hooks won't be enough, we still don't have enough info how
> to syntax-propertize the subregion contents, for instance. So I'm not sure
> what the flexibility of using the functions here would buy us.

Me neither.

Maybe the real issue is that starting from syntax-table +
syntax-propertize + font-lock is a losing proposition, and instead we
should first come up with a completely different design (from scratch)
that would be able to parse and highlight code and to accommodate
multiple major modes.  Then we can maybe see if there's a way to evolve
the current design of syntax-table + syntax-propertize + font-lock to
that new design.


        Stefan