Problem: The "%" command jumps to parens and braces inside comments,
unlike the "=" operator which ignores them.
Solution: When 'comments' defines C-style "//" or "/*" comments, skip
matching parens inside such comments, except when the cursor
is inside a comment so a match there can still be found.
The % command jumps to parens and braces inside comments, unlike the = operator (cindent), which ignores them. So on code like
foo( // ) );
% on the first ( jumps to the ) inside the // comment instead of the real one on the next line.
FM_SKIPCOMM has been implemented in findmatchlimit() since v9.2.0447 (#20111), where it was added so that cindent ignores {/}/parens inside // and /* */ comments. So the = operator already skips comment parens.
The same behavior for % was requested afterwards in #20329 and closed with a pointer to the matchit plugin — even though the infrastructure to do it cleanly (FM_SKIPCOMM) already existed at that point. So this is not a new matching feature: it is a small, natural application of code that already landed for =/cindent, and it makes the two consistent.
When 'comments' defines C-style // or /* comments, nv_percent() calls findmatchlimit() with FM_SKIPCOMM instead of findmatch(). The rule, matching what a user expects:
The "inside a comment" case is handled naturally: for a line comment the flag is not set when the cursor is past the comment leader, and for a block comment FM_SKIPCOMM does not skip the comment the cursor already sits in. Buffers without C-style comments are unaffected, so non-C filetypes keep the current behavior.
FM_SKIPCOMM from #20111 (v9.2.0447); no new matching logic.'comments', so it only applies to filetypes with C-style comments.Test_normal_percent_skip_comment cover forward/backward skipping, cursor inside a // and a /* */ comment, and the no-C-style-comments case. make test_normal passes.motion.txt documents the new behavior.https://github.com/vim/vim/pull/20491
(4 files)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Thanks. I think the buf_has_cstyle_comments() should return a bool. Also, this is also slightly backwards incompatible change. Do we have to worry about this and need a separate 'cpoption' value for it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Thanks for the review.
buf_has_cstyle_comments() should return a bool.
Done.
this is also slightly backwards incompatible change. Do we have to worry about this and need a separate 'cpoption' value for it?
I don't think we need a new flag — we can reuse the existing cpo-%
(CPO_MATCH). Its documentation already says that when % is included in
'cpoptions', % matching "Does not recognize /* and */", which implies
that when it is excluded (the Vim default) % should recognize them.
findmatchlimit() already reads cpo_match, so I'd gate the comment-skipping
on cpo-% being absent: skip parens in comments only when % is not in
'cpoptions'. That makes it opt-out through the existing Vi-compatibility
mechanism (% is in the Vi / all-flags set but not in the Vim default), and it
actually implements the behavior cpo-% already documents. 'comments' still
keeps it limited to C-style filetypes, so no new flag is needed.
Does reusing cpo-% sound good to you?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()