Consider the snippet
snippet test
${1:${VISUAL}}
endsnippet
A missing 'extend' keyword caused the inner closing bracket to end both
the inner 'snipVisual' and the outer 'snipTabStop' regions. Anything
after the inner bracket was considered 'snipSnippetBody' and thus
highlighted incorrectly.
Try to detect a snipmate-formatted file by looking at the directory name
and searching for endsnippet. If we think it's a snipmate file, switch
over to an alternative syntax highlighting variant.
In order to handle brace balancing properly, we need our own region to
match the {/} pairs, which unfortunately means that if a { occurs in a
command substitution, we have to disable the embedded language
highlighting.
Python commands tend to be longer than normal commands, and they already
include embedded python syntax coloring, so coloring them red like shell
commands is a bit overwhelming.
Preferably there would be some subtle background color we could apply,
but I don't see any pre-existing group name for that, and defining our
own would not play well with colorschemes.
The snippet/global regions were always ending correctly, but an unclosed
contained region could cause the wrong highlighting to apply to the
endsnippet/endglobal. Tweak the definitions such that the snippet/global
regions actually end at the start of the line and the footer occurs
outside the region.
Remove a few obsolete items.
Remove the snipTabsOnly item. A tab-only line is not necessarily an
error.
Color leading spaces with a red background, because the default Error
coloring doesn't affect the display of spaces.
The body of a global now only has Python syntax coloring if the trigger
is !p. This matches the actual behavior of UltiSnips. AFAIK right now
globals with other triggers are useless, but this opens the door to
proper syntax coloring for those if they ever gain a use.
Include the sh syntax for shell commands.
Make the matching on !v/!p work more accurately.
Highlight the !v/!p separately from the embedded Python/VimL.
AFAIK the only issue now is that "\`" escapes inside shell/VimL/Python
are not treated as bare "`" characters by the embedded syntax, but I
don't believe there's any way to fix that.
