-
Notifications
You must be signed in to change notification settings - Fork 61
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
Decide on scope and major functionality of this repository #32
Comments
@choldgraf me and @rowanc1 are meeting on Thursday |
But firstly, as I have started to do with https://github.com/executablebooks/markdown-it-plugin-template and https://github.com/executablebooks/markdown-it-amsmath, we should put in place the comparative python/JavaScript plugins for markdown-it |
well that is where I disagree a bit; that’s exactly what it does not do: some of the markdown-it plugins are specifically designed to just be “entry points” for passing to sphinx, then utilising its functionality (and so not bothered about the actual rendering). Obviously we do not have sphinx in JavaScript, so have to think a little differently. |
Wrote a big long issue in #34 on the plan that we agreed upon with @chrisjsewell and @fwkoch today. I think that this makes sense, although still a few outstanding things to work out. I am going to close this! |
⏬ fetch full html content when needed
I think there are a few different visions for the scope and functionality for
markdown-it-myst
. We should align on these high-level questions to make sure that we have the same goals in mind for development.@rowanc1's initial implementation here seems focused on mimicking the MyST Parser in Python (at least in terms of functionality). It focuses on "parsing to tokens and rendering to HTML using markdown-it", but doesn't have any notion of a multi-document model. In @chrisjsewell's PR he lays out a more fully-functional picture for bringing in the same functionality as Sphinx and Jupyter Book, rather than just the MyST parser.
It feels like these two approaches have different implications for how much complexity and maintenance burden we are taking on, as well as how this tool fits in with other potential tools in the ecosystem, so we should make sure we are on the same page about this.
Can we use this issue to agree on a strategy for how we're going to tackle "MyST in Javascript", and what scope this repository should have? I'd be interested in hearing @chrisjsewell and @rowanc1's thoughts on this.
The text was updated successfully, but these errors were encountered: