Breaking undo achieved through re-setting &undolevel:
Setting the value of 'undolevels' also breaks undo. Even when the new
value is equal to the old value.
[:h :undoj]
It turns out that vim.eval() will attempt to do Unicode conversion and
can fail when raw bytes are present in the unnamed register. To avoid
this problem, let's not carry the value across the bridge, and instead
store the cached value in Vim directly. This successfully sidesteps the
issue entirely, and provides the correct save and restore behavior.
This also adds a test case for the issue. Since expansion can finish
(despite the errors), the test has to capture the error messages and
examine them for a failure.
It's possible that when using _vim_dec with Python 2 that we fail to
convert the string to Unicode and just return the raw string instead.
This could happen, for instance, when there was arbitrary data in the
unnamed register during the save/restore process. During restoration,
we'd attempt to encode the string, but this may fail with a
UnicodeDecodeError as Python attempts to first convert to Unicode and
then to the requested encoding.
To fix this, let's also catch `UnicodeDecodeError` and return the raw
string if we fail to convert.
shiftwidth is zero. Per ":help shiftwidth":
shiftwidth() shiftwidth()
Returns the effective value of 'shiftwidth'. This is the
'shiftwidth' value unless it is zero, in which case it is the
'tabstop' value. To be backwards compatible in indent
plugins, use this:
if exists('*shiftwidth')
func s:sw()
return shiftwidth()
endfunc
else
func s:sw()
return &sw
endfunc
endif
And then use s:sw() instead of &sw.
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>
In windows when expanding snippets the names of the snippet files look weird because \ is not escaped properly.
Also I think there should be an option to show only part of the file name, say the path relative to ~/.vim, because this way most of the screen is taken with the paths of the file.
Going even further I think it would it look nicer if you had some kind of alignment for the string. Say "%2i: %-15s (%s)".
Of course this last suggestion might not be consensual, but maybe a option might be offered to the user.
