-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(AIP-192): Catch unpaired backticks in comments #1292
base: main
Are you sure you want to change the base?
Conversation
🤖 I detect that the PR title and the commit message differ and there's only one commit. To use the PR title for the commit history, you can use Github's automerge feature with squashing, or use -- conventional-commit-lint bot |
2d871c3
to
4ac2f2f
Compare
if prevBacktickOpen { | ||
return paired | ||
} | ||
return missingOpening |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing I realize now is that this implementation marks backticks that are both opening
and closing
as missingOpening
. Perhaps a smarter way to handle this may be to assign a priority ranking among the separators
and use that to decide whether it's missingOpening
or missingClosing
.
So for example, if
is a stronger separator than :
, you could have:
" `:thing" --> missingClosing
"thing:` " --> missingOpening
If separators had different strengths, you could perhaps use this to improve the quality of the suggestions, too. Perhaps having a rule like: "stop at the first instance of the strongest separator you see before the next backtick".
Hey @acamadeo thanks for the contribution. I'm a bit swamped and won't be able to take a deep look this week. In general though, we have avoided linting specific markdown formatting bugs because we don't want ApiLinter to become a markdown parser. The complexity of the proposed logic for just backticks is an example of why. Personally, I think it would be better if there was a separate tool to validate CommonMark syntax in proto comments, aside from ApiLinter. |
No worries, and that makes sense. I'm happy to withdraw the PR if you determine it ends up adding too much complexity to the codebase. |
Part of #1208