I’m working on a bundle to support YAML front matter in Markdown (see https://github.com/noniq/Markdown-Front-Matter.tmbundle/).
The grammar for this is easy, but I also want to strip front matter blocks (if present) from the document before processing the markdown. And it would be really cool to have this working with whatever Markdown bundle (standard, GitHub Markdown, …) the user is currently using.
So in principle I want to implement a preview command that just strips the frontmatter and then delegates to whatever else preview command would have been normally used, if this bundle would not be installed (like calling `super` in an overridden oop method).
Is this possible?
On 16 Jul 2016, at 18:41, Stefan Daschek wrote:
So in principle I want to implement a preview command that just strips the frontmatter and then delegates to whatever else preview command would have been normally used, if this bundle would not be installed (like calling `super` in an overridden oop method).
How many Markdown preview commands are out there?
The default Markdown bundle uses `TM_MARKDOWN` to convert the text to HTML so it can be used with alternative Markdown processors (I use it with multimarkdown), so not sure what the motivation would be to create new preview commands.
Is this possible?
As implied, the default command just pipes the input through whatever the `TM_MARKDOWN` variable is set to (falling back on `Markdown.pl`), so you could redefine this variable to have it strip YAML frontmatter.
In theory this can be done by a bundle (and it can even be set to something like `$TM_BUNDLE_SUPPORT/my-preprocessor`). Unfortunately though, if the user also sets `TM_MARKDOWN`, their value overrides what you have set it to.
So I think it would be necessary to introduce a defined API for sharing functionality. A command can require other bundles and reference their content, and as mentioned above, they can also set variables, so there are a few ways to go about this.
Am 16.07.16 um 21:44 schrieb Allan Odgaard:
On 16 Jul 2016, at 18:41, Stefan Daschek wrote:
So in principle I want to implement a preview command that just strips the frontmatter and then delegates to whatever else preview command would have been normally used, if this bundle would not be installed (like calling `super` in an overridden oop method).How many Markdown preview commands are out there?
There’s at least the one from Markdown (GitHub) https://github.com/MikeMcQuaid/GitHub-Markdown.tmbundle/blob/master/Commands/Preview.tmCommand (a bundle I happen to be using :-).
The default Markdown bundle uses |TM_MARKDOWN| to convert the text to HTML so it can be used with alternative Markdown processors (I use it with multimarkdown), so not sure what the motivation would be to create new preview commands.
Markdown (GitHub) also uses |TM_MARKDOWN|, but defaults to (a bundled version of) |redcarpet.rb|.
After all, I don’t really want to create a new preview command, I’d rather somehow “hook into” the existing preview command(s). (My bundle should only care about stripping the YAML front matter and not impose its own choice of markdown processor.) So setting |TM_MARKDOWN| isn’t really suitable, as far as I understand.
Maybe we could introduce something like |TM_MARKDOWN_PREPROCESSOR| into the existing preview commands? With the idea that as long as this is not set (the default) it does nothing, but if it is set the document gets piped through this first before being processed further.
On 16 Jul 2016, at 22:35, Stefan Daschek wrote:
Maybe we could introduce something like |TM_MARKDOWN_PREPROCESSOR| into the existing preview commands? With the idea that as long as this is not set (the default) it does nothing, but if it is set the document gets piped through this first before being processed further.
This sounds fine to me, however, this should probably be a list.
So your bundle would contain:
{ shellVariables = ( { name = 'TM_MARKDOWN_FILTER'; value = '$TM_BUNDLE_SUPPORT/strip-frontmatter:$TM_MARKDOWN_FILTER'; }, ); }
And the preview command would have to do a “split” and run each (non-empty) filter.
This could be exploited by users as well, for example I could set `TM_MARKDOWN_FILTER` to something that generates table-of-contents or enumerate the headings etc.
Am 16.07.16 um 22:46 schrieb Allan Odgaard:
On 16 Jul 2016, at 22:35, Stefan Daschek wrote:
Maybe we could introduce something like |TM_MARKDOWN_PREPROCESSOR| into the existing preview commands? With the idea that as long as this is not set (the default) it does nothing, but if it is set the document gets piped through this first before being processed further.This sounds fine to me, however, this should probably be a list.
So your bundle would contain:
|{ shellVariables = ( { name = 'TM_MARKDOWN_FILTER'; value = '$TM_BUNDLE_SUPPORT/strip-frontmatter:$TM_MARKDOWN_FILTER'; }, ); } |
And the preview command would have to do a “split” and run each (non-empty) filter.
This could be exploited by users as well, for example I could set |TM_MARKDOWN_FILTER| to something that generates table-of-contents or enumerate the headings etc.
Exactly! This sounds great. Should I prepare a pull request implementing this for the standard Markdown bundle ?
On 16 Jul 2016, at 22:55, Stefan Daschek wrote:
Exactly! This sounds great. Should I prepare a pull request implementing this for the standard Markdown bundle ?
Sounds good to me, and don’t be afraid to move the entire command to ruby (it’s currently a mix of bash and ruby).
I’m on vacation the next two weeks with no laptop, so I won’t be able to act on a PR until August, but maybe Michael Sheets can handle it.
On 16 Jul 2016, at 22:35, Stefan Daschek wrote:
Markdown (GitHub) also uses |TM_MARKDOWN|, but defaults to (a bundled version of) |redcarpet.rb|.
This command appears to be copy/pasted from the default Markdown bundle with the fallback value for `TM_MARKDOWN` changed to `redcarpet.rb` and the MathJax support removed (or maybe it was added after Mike cloned the command).
Mike: Would it be feasible to remove the Preview command and instead have the _Markdown (GitHub)_ bundle set `TM_MARKDOWN` to `$TM_BUNDLE_SUPPORT/bin/redcarpet.rb`?
That way, users who do not have `TM_MARKDOWN` set and install your bundle will automatically have _Markdown → Preview_ use `redcarpet.rb`.
Users who have set `TM_MARKDOWN` will still get their customer markdown processor, but that is already an issue with _Markdown (GitHub) → Preview_.
-
Allan Odgaard -
Stefan Daschek