Conversation
|
@UziTech is attempting to deploy a commit to the MarkedJS Team on Vercel. A member of the Team first needs to authorize it. |
Summary of ChangesHello @UziTech, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This PR primarily focuses on enhancing the clarity, structure, and robustness of a core regular expression used for parsing, specifically improving how it handles complex patterns like nested code within links. Additionally, it includes a minor cleanup of test file names. The changes aim to make the codebase easier to understand and maintain while improving parsing accuracy. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request refactors the blockSkip regular expression for better readability and maintainability, which is a great improvement. The use of named placeholders makes the complex regex much easier to understand. I've found a potential correctness issue in the regex used for matching code spans, which was present before this change but is now more prominent. The current implementation for code span content does not correctly handle nested backticks. My review includes a suggestion to fix this, which will make the markdown parsing more robust.
| .replace('link', /\[(?:[^\[\]`]|(?<!`)(?<a>`+)[^`]+\k<a>(?!`))*?\]\((?:\\[\s\S]|[^\\\(\)]|\((?:\\[\s\S]|[^\\\(\)])*\))*\)/) | ||
| .replace('code', /(?<!`)(?<b>`+)[^`]+\k<b>(?!`)/) |
There was a problem hiding this comment.
The regex part [^]+for matching code span content is incorrect as it doesn't allow backticks inside the code span. For example, it would fail to match a code span like ``a``. This applies to code spans within links as well as standalone code spans considered byblockSkip`.
A more robust approach is to use a non-greedy match for any character, such as [\s\S]+?, for the content. This will correctly handle cases with backticks inside the code span.
| .replace('link', /\[(?:[^\[\]`]|(?<!`)(?<a>`+)[^`]+\k<a>(?!`))*?\]\((?:\\[\s\S]|[^\\\(\)]|\((?:\\[\s\S]|[^\\\(\)])*\))*\)/) | |
| .replace('code', /(?<!`)(?<b>`+)[^`]+\k<b>(?!`)/) | |
| .replace('link', /[\[(?:[^\[\]`]|(?<!`)(?<a>`+)([\s\S]+?)\k<a>(?!`))*?\]\((?:\\[\s\S]|[^\\\(\)]|\((?:\\[\s\S]|[^\\\(\)])*\))*\)/) | |
| .replace('code', /(?<!`)(?<b>`+)([\s\S]+?)\k<b>(?!`)/) |
Marked version: 16.4.0
Description
clean up blockskip regexp
Contributor
Committer
In most cases, this should be a different person than the contributor.