Skip to content

Add support for more blockquote kinds - #1012

Closed
cestef wants to merge 3 commits into
pulldown-cmark:masterfrom
cestef:blockquote-info
Closed

Add support for more blockquote kinds#1012
cestef wants to merge 3 commits into
pulldown-cmark:masterfrom
cestef:blockquote-info

Conversation

@cestef

@cestef cestef commented Jan 25, 2025

Copy link
Copy Markdown

Another commonly used blockquote kind, I feel like we could even add support for all of them, as listed on obsidian's documentation: https://help.obsidian.md/Editing+and+formatting/Callouts#Supported+types

@Martin1887

Copy link
Copy Markdown
Collaborator

Thanks, but some tests for the new kind are required before merging 🙂.

@cestef

cestef commented Jan 27, 2025

Copy link
Copy Markdown
Author

I am not very used to this process, what do I need to do ? 😅

@Martin1887

Copy link
Copy Markdown
Collaborator

You have to add more examples in pulldown-cmark/specs/blockquotes_tags.txt and then test with the --all-features flag to update the Rust test files.

@cestef

cestef commented Feb 7, 2025

Copy link
Copy Markdown
Author

I have added tests as recommended, here is the test output:
test-results.txt

@cestef cestef changed the title Add support [!INFO] blockquote kind Add support for more blockquote kinds Feb 7, 2025
@cestef

cestef commented Feb 7, 2025

Copy link
Copy Markdown
Author

Blockquote kinds added in the PR:

  • [!INFO]
  • [!QUOTE]
  • [!SUCCESS]
  • [!FAILURE]
  • [!DANGER]
  • [!BUG]
  • [!EXAMPLE]

@Martin1887

Copy link
Copy Markdown
Collaborator

Uhm... nice addition, but I'm not sure if some of them are out of the scope of this project, since it aims to only support standard (or semi-standard) features.

@Martin1887
Martin1887 requested a review from notriddle February 7, 2025 08:47
@cestef

cestef commented Feb 7, 2025

Copy link
Copy Markdown
Author

Thanks for the feedback! Would it make sense to make support for these blockquote kinds optional via a feature flag? That way, the core parser remains focused on standard features while still allowing users who need these kinds to enable them.

@Martin1887

Copy link
Copy Markdown
Collaborator

The thing is blockquote tags are already under a feature flag, so nested or complementary flags may be cumbersome.

This change is very small, so it may be included, let's see what the rest of maintainers think about this.

@notriddle

Copy link
Copy Markdown
Collaborator

I would really prefer to add support for custom blockquote kinds that the host application can postprocess with a callback function (like the Unknown link callback we have now). It would fix #919, work better for i18n, and allow supporting even more complex directives like DocFx videos and MDN callouts.

@Martin1887

Copy link
Copy Markdown
Collaborator

It sounds much better, I agree.

@cestef

cestef commented Feb 7, 2025

Copy link
Copy Markdown
Author

This clearly sounds like a better approach indeed

@cestef

cestef commented Feb 8, 2025

Copy link
Copy Markdown
Author

The Unknown approach seems good, but there's a problem:

pub enum BlockQuoteKind<'a> {
	// ...
    Unknown(CowStr<'a>),
}

implies BlockQuoteKind can't be Copy anymore because of the string contained. Which also means that TagEnd can't be either. Would it make sense to implement a "full" enum for Tag(non-copy) and keep a basic one for TagEnd (copy) ?

Something like:

pub enum BlockQuoteKind {
    Note,
    Tip,
    Important,
    Warning,
    Caution,
    Unknown,
}

pub enum FullBlockQuoteKind<'a> {
    Standard(BlockQuoteKind),
    Unknown(CowStr<'a>),
}

But then what would ItemBody hold ? Full or basic ? it seems a bit tricky lol

@notriddle

Copy link
Copy Markdown
Collaborator

#1013

@cestef cestef closed this Feb 9, 2025
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.

3 participants