This ensure that we are actually testing against the python version that
we want to test again. A few weeks ago we still had the problem that all
our python3 tests ran against system python3 which was always 3.2. This
has been fixed a while ago, but this change makes sure we do not
regress.
Also fixes a couple of NOCOM comments that I left over in one of the
last commits.
- Remove support for python 3.2 to reduce number of test cases and because
it actually fails with Neovim. It is not a supported version anyways.
- Due to Neovim not handling fast typing through the console properly
(https://github.com/neovim/neovim/issues/2454), the typing is actually
simulated through the Python client. We need to differentiate now if a
keystroke is meant for the terminal or for the Vim session. Using
neovim.input() introduces additional chances for races since inputs
are not buffered but processed right away. This results in more
retries for some tests.
- Neovim needs more parameters and configuration passed in through the
test script. Added command line arguments for these.
- Skip an extra test under Neovim due to
https://github.com/neovim/python-client/issues/128.
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.
`augroup END` in filetype detection scripts can enclose 'filetypedetect'
group unexpectedly, makes following ftdetect auto commands be defined in
default autogroup.
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]
Without this, UltiSnips will throw a lot of errors in case it's not
available.
This does not look at `g:UltiSnipsNoPythonWarning`, because it is not
auto-detected, but provided by the user's config.
