Markdown Parser Rework #1496
Markdown Parser Rework #1496
Conversation
…n-parser-rework-rework
|
@aarnphm Just a quick check if this direction is okay before I continue implementing the fixes for the 10+ open issues related to transformers. |
…n-parser-rework-rework
|
that is, a lot of change :) |
|
probably cc @jackyzha0 once he has bandwidth source of this change is from #1424 |
Yeah, in its current form, it merely breaks up every text/markdown/html parsing step into a separate file, instead of grouping them.
This can be resolved by adding a markdown parser for non-wikilinks. Users could choose to use the non-wikilink parser over the wikilink parser should they prefer that functionality. It believe it also makes parser more extendable. Having said that, I am aware this is a breaking change, but I am not entirely sure if it is possible to make it a non-breaking change. However, I think configuration could probably be done in a more sophisticated manner. |
We did mention some structural change that you have in this PR in that issues |
quartz.config.ts
Outdated
| ], | ||
| transformers: { | ||
| textTransformers: [ | ||
| Text.ObsidianFlavoredMarkdownComments(), |
There was a problem hiding this comment.
sitting on this for a bit, I do think that this is a bit too verbose.
ig this approach is bottom-up given that the transformers are text => markdown => html
There was a problem hiding this comment.
Verbose as in function naming? That can be resolved.
There was a problem hiding this comment.
i mean having users too much control and customization (naming is a byproduct ig).
if we gave them a "gun" they will eventually end up shooting themselves in their foot.
There was a problem hiding this comment.
I see what you mean.
Having said that, most users shouldn't be touching their parsers anyway. And despite the many questions in the Discord, I have yet to get one about parsers.
There was a problem hiding this comment.
i mean having users too much control and customization (naming is a byproduct ig).
if we gave them a "gun" they will eventually end up shooting themselves in their foot.
I have given it some thought. We could create 4 (text, markdown, HTML, external resources) "parsers" that just call the default parsing order.
That would make it easy for most users, while still allowing advanced users full customization.
…n-parser-rework-rework
…n-parser-rework-rework
| @@ -0,0 +1,23 @@ | |||
| import remarkGfm from "remark-gfm" | |||
There was a problem hiding this comment.
quick comment: we can move in transformers in folders, so we don't have to have the prefix in each of these files
|
Maybe #1647 would be a related bug to fix in this branch. |
custom.scssfor parsers. We won't change the parser order to allow users to costumize.)Open parser issues
>break callouts (Obsidian inconsistency) #1628Fixed parser issues
commentRegexrenders error when multiple lines #1114