-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Centralise indented code block checks #936
Comments
Yeah, I had my doubts about this one as well for some time. Why?Not clear what the behavior should be if code rule is disabled. I wrote
How to check if code rule is present?I don't know how you manage custom rules, but this looks a bit suspicious: # pre-check if code blocks are enabled, to speed up is_code_block method
self._code_enabled = "code" in self.md["block"].ruler.get_active_rules()
Just some thoughtsMaybe block state should have something like Maybe block state should also have TL;DR: I like the idea, unsure about implementation details. |
I'd recommend just reading https://github.com/jgm/djot#rationale, this essentially details the commonmark deviations and their rationale, which also derives from https://johnmacfarlane.net/beyond-markdown.html I actually learnt of djot after asking about one of the changes it makes; to remove non-locality of reference link parsing: commonmark/commonmark-spec#702
yeh certainly open to other ideas
I like the idea, however, how could this work, given that individual rules don't have any "initialisation hook" themselves? (obviously, plugins can initialise things in |
In theory, every markdown-it rule can be wrapped in its own plugin, which can configure itself (and then there would be a single large plugin for commonmark syntax, loading smaller plugins for each individual rule). In practice, probably noone here would dedicate time and energy into changing the way it works now, and this library is too widely used to introduce breaking changes. Maybe you can do so in python, if you don't mind diverging from source code here, and if python code patterns would align that way, and if you don't get performance issues. |
Yeh ughh, I'd be very wary of doing this as obviously any divergences make it more difficult to port fixes/improvements you make here and ensure markdown-it-py is kept in-sync |
From markdown-it-rust/markdown-it#7 (comment), I see now why you suggest this 😄 So I guess this is definitely possible to add in markdown-it.rs |
I've suggested this, because markdown-it right now is in de-facto feature freeze. The project it was created for is up and running, so we don't need to fix anything. There's no time/money to make any major changes. And even if we did have resources, markdown-it is now used by too many people to justify any breaking changes. If you are porting it to python however:
If you were to do that, I have some ideas how to improve the parser. Most of these you can see in my Rust port, but not all (for example, I'm thinking this entire thing should work under ECS paradigm, which probably helps with performance and usability). That's actually why I wrote the that thing - I found out that in Rust I can refactor things a lot faster than in JS, and quickly test any ideas. |
well not on the same scale as here, but markdown-it-py has a fair few users, so certainly not trivial to change too much 😅 But yes the Rust port is looking really cool thanks, so I would rather also invest my time there and seeing what I can do with https://github.com/chrisjsewell/markdown-it-pyrs |
Not a discussion for this repo, but... "Parser plugins cannot currently be written in Python and added dynamically to the parser." What exactly is missing for that to work? I was thinking about reflection API already, and that's a good use-case for it. |
Oo very interesting 👀
Well I guess it is just trying to work where the program language barriers lie, and how to minimise that surface area Obviously, the simplest interface is strings: Then I have a "wrapper" around I then have a converter from the Rust AST to a Python AST. To have proper parser plugins, on the Python side, though, Also I'm not sure how you could "dynamically" define new Node types on the Python side, |
Please send a pull request for this library. We might get this change in (if performance impact is negligible). |
In markdown-it-py (executablebooks/markdown-it-py@9251695) and for its plugins (executablebooks/mdit-py-plugins@85f7ed3 + executablebooks/mdit-py-plugins@9e5aff8)
I have centralised the check - present in all block rules - for a block indented by greater than 4 spaces, i.e. the check for an indented code block, and deactivate it when the
code
rule is disabled.This allows for behaviour similar to e.g. https://github.com/jgm/djot and https://mdxjs.com/, whereby you can indent syntax blocks arbitrarily, e.g.
at the moment, in the code here, IMO it's a bit unintuitive that most block rules will not work like this, even if you disable code blocks
The text was updated successfully, but these errors were encountered: