Re: Bug #25608 and the comment-cache branch

[Stefan Monnier]

> comment-cache is a gross simplification of syntax.c, scanning comments
> only in the forward direction and totally eliminating
> open-paren-in-column-0-is-defun-start from syntax.c.

BTW, let me help you: eliminating open-paren-in-column-0-is-defun-start
is not terribly important and doesn't justify all those changes (my
syntax-ppss-based patch does that in a much simpler way).

The real upside to your code is the elimination of back_comment.
If I were you, that's how I'd try to sell it.

> To achieve this simplification took a lot of work.

I don't doubt it.  syntax-ppss OTOH didn't take much work at all.

>> - add a font-lock rule which highlights open-paren-in-column-0 inside
>> comments in bright red.
> Totally irrelevant to what's required.

Very relevant to:

    demoralizing work debugging bugs caused by open parens in column
    zero in comments.

since even if that highlighting is something personal in your ~/.emacs
that should make such debugging trivial, since you can easily arrange to
burp very loudly as soon as such an open paren occurs, so when you get
a bug report about it, as soon as you try to reproduce the problem with
the OP's file your hack will scream bloody murder and your debugging
will be immediately done for you.

> By the way, did you ever get around to looking at that bug which noted
> that mechanism no longer working?

No, I became more interested in using that syntax-ppss-based patch to
get rid of open-paren-in-column-0-is-defun-start in syntax.c ;-)

>> - use my syntax-ppss-based patch.
> Doesn't work all the time, in particular in narrowed buffers.

Works just fine in narrowed buffers for me, and I can't remember any bug
report about it other than yours so the problem doesn't seem nearly as
serious as you make it out to be.

BTW, your code also breaks down miserably in some narrowed buffers
(i.e. in those narrowed buffers where the narrowing semantics expected
is not the one you decided is The Only Choice).

> Of all the words in English which mean "imperfection", that's one of the
> milder ones.  Would you prefer I used "defect" or "fault" or something
> else?

How 'bout "bug"?

> If that word would provoke you into actually fixing #22983, after all
> this time, I would use it again for that purpose.

As you know, fixing this depends on figuring out how to solve the
narrowing-semantics issue.  Once a solution is chosen, fixing the bug
will be very easy.

> syntax-ppss is a cache of the syntax-table text property.
> Not invalidating the cache when a syntax-table text property is changed is
> an imperfection.  Will it be fixed?

Patch welcome.  The lack of bug-reports about it makes it a rather
low-priority issue.

>> >> 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.
>> It's only incoherent if you refuse to see the larger picture.
> The larger picture is that comment-cache can work alongside syntax-ppss
> pefectly happily without any contention.

Looks like you still haven't seen the larger picture.

>> > Can't be done, as I keep telling you.  comment-cache is solely for
>> > handling literals.
>> Then it's useless, AFAIC:
>> - we need syntax-ppss's data for lots of things.
>> - your code can't replace all those uses.
>> - so we're stuck with syntax-ppss, no matter how much you think it sucks.
>> - then we might as well use it in back_comment instead of your code,
>> since it's there and is cheap.
> But it doesn't work properly.  comment-cache is also cheap, having
> already been written and debugged.

Which part of "comment-cache is solely for handling literals" don't
you understand?

>> For that we need to provide something equivalent to
>>
>> (save-restriction
>> (narrow-to-region BEG END)
>> ...)
>>
>> but where syntax-ppss and friends will know that we shouldn't widen past
>> BEG/END ....
> I thorougly dislike the conceptualization of handling syntax as
> "widening".

Yes, sorry.  Rather than "widen" above, you should read "look".

> Introducing the new syntactic symbols "island start/end" would cater for
> with-region-as-subbuffer admirably, without having to resort to
> confusing narrowing.

What about those cases where the "subbuffer region" on which the
code wants to operate shouldn't have any special syntax-table properties
in general (the code just wants to temporarily operate on it in
a particular way).

E.g. some minor-mode may want to treat some C strings as "sub-buffer
written in some other programming language" for some specific commands,
while still keeping them as "plain old strings" in general.
If I understand correctly your suggestion of islands markers, the minor
mode would have to add those markers temporarily, then operate on the
sub-buffer and then remove them.  And along the way this causes the
whole comment-cache/syntax-ppss/font-lock state to be flushed because of
the temporary change.

In contrast, currently that minor mode could do

    (save-restriction
      (narrow-to-region BEG END)
      (with-syntax-table other-mode-syntax-table)
      ...)

which doesn't need to modify the buffer at all, and hence doesn't
invalidate any cache.


        Stefan