[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?
Stefan
- Re: Bug #25608 and the comment-cache branch, (continued)
- Re: Bug #25608 and the comment-cache branch, Dmitry Gutov, 2017/02/02
- Re: Bug #25608 and the comment-cache branch, Eli Zaretskii, 2017/02/03
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/03
- Re: Bug #25608 and the comment-cache branch, Dmitry Gutov, 2017/02/03
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/04
- Re: Bug #25608 and the comment-cache branch, Dmitry Gutov, 2017/02/05
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/06
- Re: Bug #25608 and the comment-cache branch, Dmitry Gutov, 2017/02/06
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/07
- Re: Bug #25608 and the comment-cache branch, Dmitry Gutov, 2017/02/14
- Re: Bug #25608 and the comment-cache branch,
Stefan Monnier <=
- Re: Bug #25608 and the comment-cache branch, Dmitry Gutov, 2017/02/21
- Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/21
- Re: Bug #25608 and the comment-cache branch, Dmitry Gutov, 2017/02/23
- Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/23
- Re: Bug #25608 and the comment-cache branch, Tom Tromey, 2017/02/24
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/14
- Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/16
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/18
- Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/18
- Re: Bug #25608 and the comment-cache branch, John Wiegley, 2017/02/11