It can be useful to set up mappings that apply only during expansion of
a snippet. UltiSnips does this internally with the `_setup_inner_state`
and `_teardown_inner_state` methods.
This commit adds some `User` autocommands so that users of UltiSnips can
set up their own mappings and tear them down at the same time as
`_setup_inner_state` and `_teardown_inner_state`.
This is particularly useful for people who are writing their own
expansion and jump functions using `UltiSnips#JumpForwards` and
`UltiSnips#ExpandSnippet()` and friends. Here's an example from my own
dotfiles:
- 0664b627e7
- 3740c248ee
Using this approach I've been able to get rid of Supertab and have a
more nuanced autocompletion experience that works exactly as I'd like
with YouCompleteMe.
The python module is now pulled in autoload/UltiSnips.vim. This means
that parsing of the .vimrc will only map the keys and set some options -
very cheap.
Unfortunately, the autocommands set up in plugin/UltiSnips.vim pulls in
the python code basically immediately still.
Before this, we only ever ran against system python preinstalled on
travis (i.e. 2.7 and 3.2). This change makes sure that Vim is always
build and run against the correct python version in the virtual env.
Also adds mercurial (HEAD) Vim as a testing target.
This patch took me forever to get right. At least 2 months and ~200
travis runs of trial and error - there is just too much finicky going on
with the many virtual envs on travis, Vims strange build system that
does not use python-config and LD_LIBRARY_PATH loading. En plus, the
debugging insights one can glance from travis runs are rather limited.
Detailed changes:
- Uses less sudo and only outside of scripts.
- Build correct version of Vim against correct version of Python. This
needs some LD_LIBRARY_PATH magic to make sure that Vim finds the
correct Python libraries at runtime.
- Removes dirty hack that overwrote /usr/bin/vim with the correct Vim
version to run. The test_all.py script now takes the Vim binary as a
parameter.
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.
Any test that alters the unnamed register can cause subsequent tests to
fail if there is an issues saving and restoring the register. Let's
make the test infrastructure more robust against this issue by resetting
the unnamed register to an empty string.
