Tony Brix
Tony Brix
> Remember, we have separate handling for paragraphs and inline text. Paragraphs are clipped by block tokens. They are both needed. The block tokenizer start function is not needed if...
I don't think there is a reason for it. If you would like to create a PR to make it consistent we could get it into the next major version....
> For instance: to convert some async editor tasks to synchronous tasks, the core test suite needs access to TextEditor, TextEditorElement, and both the language mode classes. TextEditor is part...
We could try doing something like that now that most of the lexer's work has been moved to the tokenizers. I would still want to make sure it isn't slowed...
#3594 is one way I can see this being done. Initial checks seem to not slow it down to much but I think it can be improved a lot.
Would you be able to do the same thing by checking if `token.type === 'code'`? Can you provide some markdown where marked renders something inside code blocks?
closing as stale. If you would like to continue working on this feel free to reopen it.
To me it is surprising that `**~~a~~**b` renders as **~~a~~**b because it doesn't work for other inline elements like `**_a_**b` which renders like **_a_**b. It seems like it should render...
I noticed this a little bit ago. I am working on moving the escaping to the renderers instead of the tokenizers. The Tokenizers should just pull the information out of...
No. The default renderers will always escape since that follows the CommonMark spec but they can be overridden