Embedded zsh code sometimes not highlighted #21
Comments
|
I've just noticed that you need to add the I'm not sure whether it means |
|
Actually, if While it should be: Besides, if you try to add another fenced code block for a vimscript code, it's wrongly highlighted as a zsh code instead. |
|
Sorry, I was wrong: you wouldn't need to add |
|
After having thought about this a little more, I think the issue is not in the zsh plugin, because you could try to include zsh code in any arbitrary number of clusters, and not necessarily in a markdown file. It's probably up to the user to find a workaround. |
|
I think it is a valid request. I'll have a look to do something similar to the vim-scala commit. That should make it simpler for embedding zsh into other syntax languages. |
|
I've ran into the contains=TOP issue while trying write a syntax file for a custom language that embeds zsh.vim and I thought it was a Vim bug; see: https://bugs.debian.org/947120:
|
|
Yes, I believe this is a Vim particularity (or bug). I remember having checked the source several years ago and noticing that behaviour, however back then I did not easily see a fix for this. |
|
@danielshahaf @lacygoill I think I have worked around the issue now. Please check |
|
Yes, I've just tested the new syntax plugin, and it fixes the issue; a fenced zsh codeblock embedded inside a markdown file is correctly highlighted as zsh code. Thank you very much for the fix. |
|
@chrisbra Thanks for the patch! However, in my case the fix doesn't quite work. Let me describe the symptoms:
I've played a bit with new :execute line and found that if I change I don't know what causes this. It could very well be that the zsh.vim change has unearthed a latent ztst.vim bug. In that case, hints would be appreciated. :-) |
|
The following patch seems to fix it: --- a/syntax/zsh.vim
+++ b/syntax/zsh.vim
@@ -371,9 +371,9 @@ syn region zshMathSubst matchgroup=zshSubstDelim transparent
\ start='\$((' skip='\\)' end='))'
\ contains=zshParentheses,@zshSubst,zshNumber,
\ @zshDerefs,zshString keepend fold
-syn region zshBrackets contained transparent start='{' skip='\\}'
+syn region zshBrackets contained transparent start='{'ms=s+1 skip='\\}'
\ end='}' fold
-exe 'syn region zshBrackets transparent start=/{/ skip=/\\}/ end=/}/ contains='.s:contained. ' fold'
+exe 'syn region zshBrackets transparent start=/{/ms=s+1 skip=/\\}/ end=/}/ contains='.s:contained. ' fold'
syn region zshSubst matchgroup=zshSubstDelim start='\${' skip='\\}'
\ end='}' contains=@zshSubst,zshBrackets,zshQuoted,zshString fold
exe 'syn region zshOldSubst matchgroup=zshSubstDelim start=/`/ skip=/\\[\\`]/ end=/`/ contains='.s:contained. ',zshOldSubst fold'I tried this because I suspected that both the l374 and l376 definitions matched the opening brace, so I hoped two closing braces would terminate the region and then (at the end of the line, in my case) relinquish control back to the enclosing syntax file. |
|
I suppose the zsh syntax file does not correctly determine that it is being embedded. Perhaps I need to detect another cluster as well. @danielshahaf can you please share the test case? I'd like to have a look. In particular, I am wondering how the or other way around: What do I need to do to have such a test case opened in Vim with the filetype/syntax scripts set to |
|
@chrisbra Sure. ztst.vim is defined here: https://github.com/zsh-users/zsh/blob/master/Util/ztst-syntax.vim. Sorry, I forgot to make it a link in my previous comment. If you install that file as ~/.vim/syntax/ztst.vim, open https://github.com/zsh-users/zsh/blob/master/Test/A01grammar.ztst, and manually ztst.vim includes zsh.vim under the Does this answer your question? If not, I'd be happy to provide any info you need. |
|
that is strange. Not sure what is causing it. However it seems like |
I issued this command manually and it did not fix the problem for me. I also tried deleting lines 1 through 800, so the aforelinked test case (nominally on lines 801-814) would be the very first thing in the file, and could still see the wrong highlighting then. I'm not sure why I'm seeing different behaviour than you do. I'm attaching my |
|
As to maxlines: in ztst.vim I set |
|
Hm, looks like I was wrong or I misunderstood something. Earlier you said:
I actually always thought this is not possible, but I believe this is indeed what happened. With commit e29a10b However with commit a0f17e0 So let me include your suggested change and see if somebody complains. If yes, we might have to backout a0f17e0 again, as it seems to cause more harm that it solves. |
When zsh is embedded into other syntaxes, it can happen, that the zshBrackets (and possibly other groups as well) match several times on the starting a syntax region. See e.g. #21 (comment) So include a match-offset of one character so that the same group cannot match at the same time several times. Signed-off-by: Christian Brabandt <cb@256bit.org> Signed-off-by: Daniel Shahaf <danielsh@apache.org>
|
regarding your other message, I think I see why the comments are note matched. I believe the issue is this: I believe this match makes it impossible to have the zshComment match at the same time, because both patterns like to anchor against the start of the line: For reference the zshComment This requires either a space or the start of line before the comment. However, since the You can try, if this patch to the ztst syntax fixes it: diff --git a/ztst-syntax.vim b/home/chrisbra/.vim/syntax/ztst.vim
index 01e4dae..8efdc71 100644
--- a/ztst-syntax.vim
+++ b/home/chrisbra/.vim/syntax/ztst.vim
@@ -52,7 +52,7 @@ syn region ztstFrequentExplanation start=// end=/$/ contained
syn match ztstDirective /^%.*/
-syn match ztstComment /^#.*/
+syn match ztstComment /^\s*#.*/
" Highlight those variables which are /de jure/ or /de facto/ APIs of the test
" harness to the test files.on the other side, I am not sure why |
Thanks! Yes, if that change causes a regression, we can always go back to the drawing board here.
Thank you very much for the diagnosis :-). Instead of letting ztstComment gobble the spaces, I'' remove the diff --git a/Test/D02glob.ztst b/Test/D02glob.ztst
index 3d7df94c9..a6ff087a9 100644
--- a/Test/D02glob.ztst
+++ b/Test/D02glob.ztst
@@ -635,6 +635,9 @@
[[ a = ['!a'] ]]
0:! not active in character class if quoted
+ echo 'foo
+ # bar
+ '
# Actually, we don't need the quoting here,
# c.f. the next test. This just makes it look
# more standard.Cheers! |
certain syntax elements are defined as `contained=TOP`. However, when embedding the zsh syntax into another language like pandoc or markdown does, this will prevent to match those syntax items, because the top level items will then be used for the top level syntax language markdown/pandoc and not zsh. Therefore, check if the @zsh or @markdownHighlightzsh cluster is defined and if so, instead of defining `contains=TOP` use the correct `contains=@<cluster>` (which should be the cluster defined for the embedded lanuage, e.g. either @zsh for pandoc or @markdownHighlightzsh cluster for markdown). closes #21
When zsh is embedded into other syntaxes, it can happen, that the zshBrackets (and possibly other groups as well) match several times on the starting a syntax region. See e.g. #21 (comment) So include a match-offset of one character so that the same group cannot match at the same time several times. Signed-off-by: Christian Brabandt <cb@256bit.org> Signed-off-by: Daniel Shahaf <danielsh@apache.org>
Hello,
According to the readme page of Vim's default markdown syntax plugin (and
:h rmd.vim), one can embed some code in a markdown file, provided that it's surrounded in a fenced code block, and the variableg:markdown_fenced_languagesis set correctly.For example, if you set the variable like this:
And you write this in a markdown file:
echo 'hello'should be highlighted like it would be in a Vimscript file.Some syntax groups defined in
$VIMRUNTIME/syntax/zsh.vimuse the argumentcontains=TOP.I think that because of this, sometimes, when a zsh code is embedded in a markdown file, some part of it may not be highlighted.
Here's a MWE:
The previous shell command creates the file
/tmp/md.md, in which there's a fenced code block containing a zsh function. The next one starts Vim with a minimum of configuration, and opens/tmp/md.md:The embedded zsh code is not highlighted:
For the time being, I deal with this issue by redefining the syntax groups
zshSubst,zshBrackets,zshOldSubst, and replacingcontains=TOPwithcontains=@markdownHighlightzsh, but only when the cluster@markdownHighlightzshexists.Here's how it works:
The previous shell command creates a minimal vimrc whose only purpose is to redefine the 3 syntax groups mentioned earlier. The next one starts Vim with this minimal vimrc:
This time, the zsh code is correctly highlighted:
Unfortunately, I think this is brittle, as it could probably break if the code of the zsh syntax plugin changed in the future.
I wondered whether it would be possible for the plugin to use
contains=TOPonly on the condition that the cluster@markdownHighlightzshdoes not exist. If it does, it would usecontains=@markdownHighlightzshinstead.But there's another issue. The default markdown syntax plugin uses the cluster
@markdownHighlightzsh, but I use my own syntax plugin which uses the cluster@markdownEmbedzsh. And maybe other markdown syntax plugins use yet another name for this kind of cluster.Do you think it would be possible to add an option that the user could set with the name of their cluster? By default, it would be set with
markdownHighlightzsh, because that's what the default markdown syntax plugin uses; but the user could override it in their vimrc.If you think an option is too much, I can understand. I could replace
@markdownEmbedzshwith@markdownHighlightzshin my plugin.For reference, here are some links to similar issues:
derekwyatt/vim-scala#59
vim-pandoc/vim-pandoc-syntax#54
Feel free to close the issue if you think it's not important.
Thank you very much for your plugin.
The text was updated successfully, but these errors were encountered: