The markdown-redcarpet bundle [1] supports fenced code blocks with syntax highlighing, for example for shell scripts. The grammar pattern is:
fenced_block_shell = { name = 'markup.raw.block.markdown.fenced'; begin = '(^|\G)([`]{3})[ ]*(?:bash|shell|sh)$'; end = '(^|\G)([`]{3})(\n|\z)'; patterns = ( { include = 'source.shell'; } ); };
This works fine, unless if have a block like:
```shell dd bs=1m if=foo.img of=/dev/disk1 ```
Here, “if” starts the scope “meta.scope.if-block.shell”, and this scope extends beyond the ``` the end of the fenced code block, resulting in incorrect highlighting for the rest of the markdown file.
Is there a way to include grammars in a way making sure the included grammar does not extend beyond the “end marker” in any case?
And: Could the rule for if-blocks in the shellscript bundle be more strict (matching only '^\s*if\b' for example)? Is this rule needed at all? (I haven’t found any other references to the scope “if-block” in the shellscript bundle.)
Stefan
[1]: https://github.com/streeter/markdown-redcarpet.tmbundle
On 11 Jul 2014, at 11:01, Stefan Daschek wrote:
[…] have a block like:
dd bs=1m if=foo.img of=/dev/disk1Here, “if” starts the scope “meta.scope.if-block.shell”, and this scope extends beyond the ``` the end of the fenced code block, resulting in incorrect highlighting for the rest of the markdown file.
Is there a way to include grammars in a way making sure the included grammar does not extend beyond the “end marker” in any case?
This is not possible. There are probably enough use-cases to justify adding new syntax for this, so I’ll add it to the list of potential future improvements.
And: Could the rule for if-blocks in the shellscript bundle be more strict (matching only '^\s*if\b' for example)? Is this rule needed at all? (I haven’t found any other references to the scope “if-block” in the shellscript bundle.)
I think it could, best way to figure out is to make the change, test it, and submit a PR if you do not see any issues :)
Be sure not to assign any scope beyond meta.* to potentially matched leading whitespace.
I want to run with command-R a bash program that runs a GAMS program, which itself produces output in file called tmp.out. This is already loaded in my Textmate project so running the GAMS program usually updates the textmate load copy of tmp.out to the results of the most recent run. I have two questions:
- sometimes the update doesn't work and I can't figure out why?
- do I need to do to be able to run the bash program with command-R?
Bill Gibson
On 14 Jul 2014, at 18:11, Bill Gibson wrote:
I want to run with command-R a bash program that runs a GAMS program, which itself produces output in file called tmp.out. This is already loaded in my Textmate project so running the GAMS program usually updates the textmate load copy of tmp.out to the results of the most recent run. I have two questions:
- sometimes the update doesn't work and I can't figure out why?
Are you saying that you have a file open (tmp.out) which has been changed on disk (by your bash script) and TextMate does not notice this (and thus, does not reload the file)?
If so, I am not sure what could cause that.
- do I need to do to be able to run the bash program with command-R?
If the bash script is in the current document than ⌘R should run it. If not then do you want ⌘R to always run this script, regardless of current document, if so you need to create a TextMate command, but if you only want ⌘R to run it when files from the same folder is open, then I suggest creating a Makefile to run it, by default ⌘B will “build” the current Makefile goal and ⌘R will build the Makefile goal named ‘run’ (unless you set TM_MAKE_RUN_TARGET).
And: Could the rule for if-blocks in the shellscript bundle be more strict (matching only '^\s*if\b' for example)? Is this rule needed at all? (I haven’t found any other references to the scope “if-block” in the shellscript bundle.)
I think it could, best way to figure out is to make the change, test it, and submit a PR if you do not see any issues :)
Be sure not to assign any scope beyond meta.* to potentially matched leading whitespace.
Pull request: https://github.com/textmate/shellscript.tmbundle/pull/18
I decided not to delete the scope because there are similiar scopes like `meta.scope.while-loop.shell`, and though I couldn’t find any references to those scopes in any bundles I suspect they could be used for syntax highlighting.
(The `if-block` scope was introduced in https://github.com/textmate/shellscript.tmbundle/commit/3a30a60, but the commit message doesn’t say anything about why it was added.)
Stefan
On 24 Jul 2014, at 22:22, Stefan Daschek wrote:
[…] Be sure not to assign any scope beyond meta.* to potentially matched leading whitespace.
Pull request: https://github.com/textmate/shellscript.tmbundle/pull/18
Thanks, I commented on the PR with a possible improvement to the regexp.
I decided not to delete the scope because there are similiar scopes like `meta.scope.while-loop.shell`, and though I couldn’t find any references to those scopes in any bundles I suspect they could be used for syntax highlighting.
The scopes can also affect behavior/settings and the Select Scope (⌥⌘B) functionality, though for the latter, it’s fine that we get the leading whitepsace included in the selection (where caret is inside an `if`…`fi` expression).
-
Allan Odgaard -
Bill Gibson -
Stefan Daschek