feat(AIP-192): Catch unpaired backticks in comments #1292
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 |
acamadeo
force-pushed
the
closed-backticks
branch
from
2d871c3
to
4ac2f2f
Compare
| if prevBacktickOpen { | ||
| return paired | ||
| } | ||
| return missingOpening |
There was a problem hiding this comment.
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