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. |
|
hmm, I look into remark and unist ecosystem a bit, fwiw I'm considering writing remark-obsidian and rehype-obsidian during the break :) at least short term plan is to also treat this similar to how gfm is supported with remark and rehype. What do you think emile? Probably would also reduce the overhead for us :) |
You know. That would actually be a way more robust solution. Do you want me to look into that, or do you prefer to take care of implementing that? I could work on proposing a plugin interface if you prefer to work on the parsers. EDIT: there seems to be already a basic implementation: https://github.com/johackim/remark-obsidian Not sure how good it is. It is also GPL-licensed. |
|
I think quartz is a lot more feature-full comparing to that, but I will def give them remarks |
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