Skip to content
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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

acamadeo
Copy link
Contributor

Part of #1208

@acamadeo acamadeo requested a review from a team as a code owner November 29, 2023 02:56
Copy link

🤖 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 automerge label. Good luck human!

-- conventional-commit-lint bot
https://conventionalcommits.org/

if prevBacktickOpen {
return paired
}
return missingOpening
Copy link
Contributor Author

@acamadeo acamadeo Nov 29, 2023

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".

@noahdietz
Copy link
Collaborator

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.

@acamadeo
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants