Closed ndemie closed 3 years ago
Hey @ndemie , unfortunately there's not much we can do to affect the commonmark parser outside of the options specified in DownOptions
. However it should be fairly straightforward to achieve what you want using a custom styler. As you mentioned, the default styler renders elements that you don't want, but you could create your own subclass of the default styler and simply override certain styling methods with an empty implementation. It would look something like this:
class SimpleStyler: DownStyler {
override func style(blockQuote str: NSMutableAttributedString, nestDepth: Int) {
// When this is called, we won't do anything, so block quotes will not have any special appearance.
}
}
You'd then pass an instance of your styler when rendering your markdown. I hope this helps, let me know how it goes.
Hey @ndemie , unfortunately there's not much we can do to affect the commonmark parser outside of the options specified in
DownOptions
. However it should be fairly straightforward to achieve what you want using a custom styler. As you mentioned, the default styler renders elements that you don't want, but you could create your own subclass of the default styler and simply override certain styling methods with an empty implementation. It would look something like this:class SimpleStyler: DownStyler { override func style(blockQuote str: NSMutableAttributedString, nestDepth: Int) { // When this is called, we won't do anything, so block quotes will not have any special appearance. } }
You'd then pass an instance of your styler when rendering your markdown. I hope this helps, let me know how it goes.
That indeed works for not applying styling, however the special trigger characters as part of the markdown spec (such as '>' for blockquote) still get lost.
Judging by your answer there is currently no way to circumvent this?
@ndemie these characters are lost because they're considered delimiters in the source string and the cmark parses doesn't preserve them all. However, you can (in most cases) reconstruct them from the syntax tree produced by cmark, by inserting them manually at the right places before the styling takes place. For instance, at this line you would want to prepend the >
character to result
, or several of these characters depending on the depth of the block quote.
But note that you couldn't fully replicate what is contained in the source string. For example, should you also include a space after the >
? There isn't anything in the syntax tree to indicate the there was a space in the source string. These kinds of ambiguities occur in several other cases, so depending on you requirements, it might not be the solution you're looking for.
The only true way to do this is to prevent the parser from attempting to parse things like block quotes, which would need to be done in cmark and not Down.
Thank you for the thorough answer. It makes complete sense. We've decided to support and render these types with their own custom styling, but not allow the user to mark them up in the UI. So if the user knows we use CommonMark they can still apply it and it'll get rendered properly, but it shouldn't happen much in practice
@ndemie I'm happy to help, also for any further question you have.
Please help prevent duplicate requests before submitting a new one:
Feature Request
We would like to be able to disable certain parts of the CommonMark spec in the library. We want to support certain things (bold, italic, underline, headings, lists) but not support other things such as blockquotes and code blocks
Describe alternatives you've considered
Not passing along styling properties for the things we do not want to support, however they seem to have a default styling applied regardless.