[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug #25608 and the comment-cache branch

From: Stefan Monnier
Subject: Re: Bug #25608 and the comment-cache branch
Date: Tue, 14 Feb 2017 11:38:06 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

> What is "it"? I would imagine that to be sure that point is not
> e.g. inside a string, the patch would have to consult the cache (or call
> syntax-ppss) at least once per forward-comment call.

Like all the sexp movement functions, `forward-comment` is allowed to
assume that the starting position is outside of comments/strings, so it
doesn't need to consult the cache to see if it's within a string.

In the case we do scan forward (e.g. the case where we end up using
parse-partial-sexp (or syntax-ppss in my patch)), we actually manually
re-introduce that behavior: if the forward parse says that the
end-comment-marker in inside a string (or inside another comment), we
re-parse from the beginning of that string (or comment) to try and see
if that end-comment-marker could be considered to close a comment nested
within the string (or the other comment).

> From there, I don't really see a real need for backward comment scanning.
> So if you rewrote some code to use forward scanning, that approach should be
> applicable on top of the AP as well.

Calling syntax-ppss every time back_comment is invoked would probably
result in bad performance currently: when parsing backward
(e.g. backward-sexp), the syntax-ppss-last optimization is ineffective,
so we'd fallback on syntax-ppss-cache which ends up scanning on the
average syntax-ppss-max-span/2 (i.e. 10K) chars.  When \n is a comment
ender (i.e. in most programming language modes), it would imply
a forward scan of 10K for every line.

IOW, for such an approach to work, we'd have to rework syntax-ppss to be
faster when scanning backward (e.g. reduce syntax-ppss-max-span, which
would have other repercussions).

>> That sounds like you've decided you want to use syntax-ppss no matter

There's no alternative to syntax-ppss on the table, AFAIK.

>> what, and the bugs this will cause will just be relabeled as features.

Care to back up this claim?

Where/when have we claimed that what you consider as a syntax-ppss bug
is a feature?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]