1. The keys after launching vim will wait until the vim is full loaded.
2. The keys after leaving vim will wait until the vim process is dead.
3. A bunch of cleanups.
It may detect the need-screen-escape incorrectly or not invoke the vim
subprocess in the first test case. These could be fixed by adding a
short sleep.
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.
In py2 we could get by with attempting to encode/decode a string and if
it failed just ignore and return. Unfortunately on py3 a string decodes
to a bytearray and a bytearray encodes to a string. We can't simply
return the original object when we fail. We choose replace for handling
bytes we don't understand.
Test case (using python3 for UltiSnips):
open a new file
:set encoding=utf-8
qa<Backspace>q
"ap
Warning: this test case makes it very difficult to exit vim cleanly and
save files!
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
