-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Allow (pre)parser extension #700
Comments
Have you tried to write an inline Vite plugin to do the transformation? If that can't help, I am fine to expose some capability for such customization |
I'll have a look at what can be done with vite, it is still some tech I don't know very well. |
@antfu can vite plugins "intercept" a file read with slidev/packages/parser/src/fs.ts Line 9 in df066d4
I tried a simple plugin but it seems to be called with individual virtual 1.md 2.md ... files (but not the entry point). |
I see. PR welcome to propose your interface in mind (or if you want to start with a more detailed API design first would also be great) |
I started thinking about it, I imagine a few callbacks from the parser to the plugin, do you prefer a style where there is an api with several methods or rather a single method with an kind of event type (i.e. the plugin implements a single method, that is a if (type == '') .... elif ....)? For the "chain" aspect, where e.g. several (slidev) addons can each add a parser plugins and the user folder can also add parser plugins, |
NB: The (chained) injection unfortunately runs in the client but the preparser is on the node side so it means I'll have to update the server extension code, i.e.,
|
NB: the situation is even more tricky as:
I've come up with a somewhat convoluted solution where the node module injects an addon loader function into the parser that calls it when it has found the headmatter. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Is your feature request related to a problem? Please describe.
For some presentation that aggregate subslides, it takes a lot of space to even write the front matter with the two
---
(one after the frontmatter, and one after the (empty) content) + the empty line.With a custom syntax for includes, I had in a previous system:
Which now takes a lot of vertical boilerplate:
There are other cases where a custom compact notation would be nice to have (e.g. open a slide at every
# bla title
, so no---
everywhere) (e.g. alternate syntax to open a slide with a specific layout,@cover(bg.jpg)
, etc).For some use cases, the solution below might be also simpler than adding rules to the markdownit parser (but the blocking point is really the things that happen before markdown parsing, so the split at
---
).Describe the solution you'd like
A flexible, minimal-change solution would be to add an extension point to the parser, that addons and the user can customize.
E.g. allow to call a (chain of) custom parsers for instance here
slidev/packages/parser/src/core.ts
Line 130 in fb8054f
Things to consider without too much filtering:
Describe alternatives you've considered
I could write a script (bash, python) that generates the actual md file...
The text was updated successfully, but these errors were encountered: