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

Create DelimiterSyntax to replace TagSyntax #407

Merged
merged 16 commits into from
Apr 14, 2022
Merged

Create DelimiterSyntax to replace TagSyntax #407

merged 16 commits into from
Apr 14, 2022

Conversation

chenzhiguang
Copy link
Contributor

@chenzhiguang chenzhiguang commented Apr 5, 2022

Introduces a new syntax DelimiterSyntax which has the same parsing strategy as TagSyntax, but more flexible.

For example:

const text = '#####tag#####';

final result = markdownToHtml(text, inlineSyntaxes: [
  DelimiterSyntax('#+', requiresDelimiterRun: true, tags: [
    DelimiterTag('flash', 5),
  ]),
]

output:

<p><flash>tag</flash></p>

This PR also add anther syntax EmphasisSyntax, which replaces TagSyntax(r'\*+', requiresDelimiterRun: true) and TagSyntax(r'_+', requiresDelimiterRun: true)


@kevmoo
Copy link
Member

kevmoo commented Apr 5, 2022

This is going to need a changelog entry – right?

@kevmoo kevmoo requested a review from srawlins April 5, 2022 18:46
@chenzhiguang
Copy link
Contributor Author

This is going to need a changelog entry – right?

Yes

Because

+ Intraword emphasis with * is permitted
+ Intraword emphasis with _ is not permitted
@chenzhiguang
Copy link
Contributor Author

Sorry to keep committing new stuffs to this PR.
Now I am done. I will create another PR if I find any new issues or want to commit anything new.

Copy link
Member

@srawlins srawlins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this is a breaking change, even leaving TagSyntax intact: Some fields now return DelimiterSyntax instead of TagSyntax, and StrikethroughSyntax no longer extends TagSyntax.

If you like, you can add a CHANGELOG entry, and bump the major version number in pubspec.yaml and lib/src/version.dart.

@@ -972,7 +1016,7 @@ class LinkSyntax extends TagSyntax {
@override
Node? close(
InlineParser parser, covariant SimpleDelimiter opener, Delimiter? closer,
{required List<Node> Function() getChildren}) {
{String? tag, required List<Node> Function() getChildren}) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style nit: please add a trailing comma here, so that each parameter appears on its own line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

{required List<Node> Function() getChildren}) {
return Element('del', getChildren());
}
/// Parses `==mark==` to `<mark>mark</mark>`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add some documentation about where this is coming from? We need specifications which we can follow in order to support special syntaxes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not find a common used specification about it.

My idea is all the syntaxes extend DelimiterSyntax with requiresDelimiterRun = true follow the commonmark specification of Emphasis and strong emphasis: https://spec.commonmark.org/0.30/#emphasis-and-strong-emphasis

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can support an unspecified, or loosely specified syntax. Even if it is not a complicated one, it adds maintenance burden, and can create breaking changes when a well-specified, popular syntax does emerge, and is slightly different from what we've implemented. As is noted in the issue, some implementations seem to support different delimiters for highlighting, so I think this is too under-specified to accept.

I'll comment more on the issue.

/// Create a new [TagSyntax] which matches text on [pattern].
final List<DelimiterTag>? tags;

/// Create a new [DelimiterSyntax] which matches text on [pattern].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Fixed

class DelimiterTag {
DelimiterTag(this.tag, this.indicators);

// Tag name of AST Element
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grammar nit: "Tag name of the HTML element." (ending with a period)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

final String tag;

/// The length of [indicators]
final int indicators;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name of this field is probably not the best (as seen by the doc comment above it).

I would expect a field named 'indicators' to the String perhaps, or a List. This should be renamed to something like... 'indicatorLength'. If that is too long, I'd be open to other ideas...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have changed it to indicatorLength. Yes, indicatorLength is too long, this was the reason why I named it indicators.

{required List<Node> Function() getChildren}) {
var strong = opener.length >= 2 && closer.length >= 2;
return Element(strong ? 'strong' : 'em', getChildren());
{required String tag, required List<Node> Function() getChildren}) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style nit: please add a trailing comma here, so that each parameter appears on its own line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. I thought we prefer to use this no trailing comma style.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually don't have a strong preference. Except when we have some long parameters (like with the required keyword), and now they're creeping onto a third line. In the analyzer codebase we've been moving towards using trailing commas more. It's not a hard rule yet.

@chenzhiguang
Copy link
Contributor Author

chenzhiguang commented Apr 8, 2022

Note that this is a breaking change, even leaving TagSyntax intact: Some fields now return DelimiterSyntax instead of TagSyntax, and StrikethroughSyntax no longer extends TagSyntax.

If you like, you can add a CHANGELOG entry, and bump the major version number in pubspec.yaml and lib/src/version.dart.

Done!

@chenzhiguang
Copy link
Contributor Author

Will we merge this PR? I'm waiting for the merge to continue with other tasks to avoid a lot of conflicts. Thanks!

Copy link
Member

@srawlins srawlins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that DelimiterSyntax is a fine improvement over TagSyntax, and I think we can definitely merge this PR with that feature.

But I don't think the HighlightSyntax should be a part of all this. The DelimiterSyntax definitely makes HighlightSyntax easier, so that others can implement this syntax, and perhaps other extensions for other Markdown flavors.

@chenzhiguang
Copy link
Contributor Author

Thanks! HighlightSyntax has been removed.

Yes, I agree, we should only focus on the standard syntaxes / flavors.

Copy link
Member

@srawlins srawlins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice feature, thanks!

@srawlins srawlins merged commit 6d39147 into dart-lang:master Apr 14, 2022
@chenzhiguang chenzhiguang deleted the Improve-TagSyntax branch April 18, 2022 14:57
roubachof pushed a commit to roubachof/markdown that referenced this pull request Jul 1, 2022
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.

Incorrect Parsing of Strikethrough Tags When Mixed with Emphasis and Order Changes
3 participants