Hi!
I’m trying to match the triple-backticks raw block Markdown extension e.g.:
``` this is a raw block ```
I’m using the following pattern:
{ name = 'markup.raw.block.markdown'; begin = '(^|\G)([`~]{3,})'; end = '(^|\G)([`~]{3,})'; beginCaptures = { 2 = { name = 'punctuation.definition.raw.markdown'; }; }; },
Unfortunately this just seems to never “end” and just matches the “begin” repeatedly.
Does anyone have any suggestions here?
Thanks!
Mike McQuaid http://mikemcquaid.com
On 07 Jan 2016, at 14:00, Mike McQuaid mike@mikemcquaid.com wrote:
Does anyone have any suggestions here?
You can have a look at how it's done in https://github.com/streeter/markdown-redcarpet.tmbundle
On 7 Jan 2016, at 13:36, Elia Schito elia@schito.me wrote:
On 07 Jan 2016, at 14:00, Mike McQuaid mike@mikemcquaid.com wrote:
Does anyone have any suggestions here?
You can have a look at how it's done in https://github.com/streeter/markdown-redcarpet.tmbundle
Copying their “begin”/“end” seems to produce the same result as mine did so it’s perhaps a higher-level problem causing this nesting failure.
Mike McQuaid http://mikemcquaid.com
On 7 January 2016 at 14:00, Mike McQuaid mike@mikemcquaid.com wrote:
Hi!
I’m trying to match the triple-backticks raw block Markdown extension e.g.:
this is a raw blockI’m using the following pattern:
{ name = 'markup.raw.block.markdown'; begin = '(^|\G)([`~]{3,})'; end = '(^|\G)([`~]{3,})'; beginCaptures = { 2 = { name = 'punctuation.definition.raw.markdown'; }; }; },Unfortunately this just seems to never “end” and just matches the “begin” repeatedly.
Interesting, that does work for me.
For completeness sake, this is in the grammar repository:
raw_block = { patterns = ( { name = 'markup.raw.block.markdown'; begin = '(^|\G)([ ]{4}|\t)'; while = '(^|\G)([ ]{4}|\t)'; }, { name = 'markup.raw.block.fenced.markdown'; begin = '(^|\G)([`~]{3,})'; end = '(^|\G)([`~]{3,})'; beginCaptures = { 2 = { name = 'punctuation.definition.raw.markdown'; }; }; }, ); };
and I tested with this snippet of text:
This is some text
This is a raw block
``` This is another raw block ```
This is some more text
Both raw blocks are recognized as such, as are both paragraphs.
Is your TextMate up to date? (2.0-beta.8.5 is the latest "normal" release.) Have you made any other modifications to your Markdown bundle?
Sorry, Martin
Does anyone have any suggestions here?
Thanks!
Mike McQuaid http://mikemcquaid.com
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 7 Jan 2016, at 15:53, Martin Kühl martin.kuehl@gmail.com wrote:
Is your TextMate up to date? (2.0-beta.8.5 is the latest "normal" release.)
Yep.
Have you made any other modifications to your Markdown bundle?
I deleted and reinstalled it to make sure but: nope.
This is the current state of my GitHub Markdown injection bundle: https://github.com/mikemcquaid/GitHub-Markdown.tmbundle/blob/fix-raw-markdow...
Mike McQuaid http://mikemcquaid.com
On 7 January 2016 at 20:52, Mike McQuaid mike@mikemcquaid.com wrote:
This is the current state of my GitHub Markdown injection bundle: https://github.com/mikemcquaid/GitHub-Markdown.tmbundle/blob/fix-raw-markdow...
Thanks. It seems like an injection issue to me.
I haven’t played with them nearly enough yet, but changing the injection selector to
text.html.markdown#block#raw_block
seems to fix the issue you’re seeing.
Hope that helps, Martin
On 7 January 2016 at 23:01, Martin Kühl martin.kuehl@gmail.com wrote:
On 7 January 2016 at 20:52, Mike McQuaid mike@mikemcquaid.com wrote:
This is the current state of my GitHub Markdown injection bundle: https://github.com/mikemcquaid/GitHub-Markdown.tmbundle/blob/fix-raw-markdow...
Thanks. It seems like an injection issue to me.
Thinking about this more, I believe this is a bug. The `L:` prefix seems to cause the injected begin matcher to match even before its own end matcher can, as you described.
The tmLanguage file Mike linked reproduces the problem, we can remove the first two patterns to further reduce it. Removing the `L:` prefix from injectionSelector fixes the problem.
-Martin
On 8 Jan 2016, at 08:18, Martin Kühl martin.kuehl@gmail.com wrote:
Thinking about this more, I believe this is a bug. The `L:` prefix seems to cause the injected begin matcher to match even before its own end matcher can, as you described.
Thanks Martin, that sorts it out for me. I don’t really understand why but it works so I’ll try to forget about it ;)
The tmLanguage file Mike linked reproduces the problem, we can remove the first two patterns to further reduce it. Removing the `L:` prefix from injectionSelector fixes the problem.
I’ll leave the branch there for a while so people can take a look.
Thanks again!
Mike McQuaid http://mikemcquaid.com
On 8 Jan 2016, at 9:18, Martin Kühl wrote:
Thinking about this more, I believe this is a bug. The `L:` prefix seems to cause the injected begin matcher to match even before its own end matcher can,
The `L:` prefix means “inject the rules before the current context’s rules”.
What happens here is that we inject a begin/end match, each for `~~~`.
Once we match `~~~` we start a new context, in this new context, the injection grammar is once again injected, so once we see the ending `~~~` it is actually matched by a new instance of the injection grammar, because we inject it before the current context’s rules (in which we find the rule to match the ending `~~~`).
So one solution is to remove the `L:` prefix so that we check the current context’s rules before the injection grammar’s.
Another solution is to make the scope selector: `L:(text.html.markup $)` to only inject the rules when we are at the root level of the document. Alternatively `L:(text.html.markup - markup.raw.block.markdown)` to just avoid injecting it into fenced code blocks.
On 10 January 2016 at 23:37, Allan Odgaard mailinglist@textmate.org wrote:
On 8 Jan 2016, at 9:18, Martin Kühl wrote:
Thinking about this more, I believe this is a bug. The `L:` prefix seems to cause the injected begin matcher to match even before its own end matcher can,
The `L:` prefix means “inject the rules before the current context’s rules”.
What happens here is that we inject a begin/end match, each for `~~~`.
Once we match `~~~` we start a new context, in this new context, the injection grammar is once again injected, so once we see the ending `~~~` it is actually matched by a new instance of the injection grammar, because we inject it before the current context’s rules (in which we find the rule to match the ending `~~~`).
I guess my assumption was that the injection scope would refer to a piece of a grammar, analogous to what `include` refers to.
Am I understanding correctly then that an injection scope: * refers to (and is compared to) a scope in the active document? * is valid for the whole (injected) grammar
Is there a way to inject different rules into different scopes or would one create multiple injected grammars for that?
Now to help me understand…
Let's assume our position is inside some scope S opened by a `begin`/`end` rule. Let's call its `end` matcher END and its included rules INC. TM would try matching END, then INC, right? Let's abbreviate that as [ENC, INC].
There is another grammar supposed to inject rules into the current scope, let's call its rules INJ. If I understand correctly, injecting into scope "S" would result in trying [END, INC, INJ], while injecting into "L:S" would result in trying [INJ, END, INC], right?
What do the R and B prefixes do? I can imagine R being useful for lowering priority in the face of several injected grammars, is that the intended purpose?
Is there a way to inject the grammar such that TM would try [END, INJ, INC]?
Thanks for your patience, Martin
-
Allan Odgaard -
Elia Schito -
Martin Kühl -
Mike McQuaid