The 'sh' filetype in Vim covers sh, bash and ksh. This function looks
for declared variables that results from Vim's own test. The global
variables are checked first since they are typically specifed by the
user in .vimrc
Modify new_scratch_buffer method to leave the created buffer in command
rather than insert mode. Currently the only use of this method is for
showing stack traces for errors, when that happens it's much more likely
that the user will want to use command mode to move around than to use
insert mode to add text to the beginning of the buffer.
Exercise changes from commit 7335225, to check that the problem fixed by
that doesn't recur.
I've run all tests including this one both with and without the
previously mentioned commit, the new test only passes if that commit is
included. All other tests pass in either case.
Debian unstable currently has a pre-release version of screen 4.1.0.
This version changes the "stuff" command so that special characters get
parsed, breaking many of the tests.
Detect if the version of screen being used to run tests does this
parsing, and if so do additional escaping of characters so that tests
again work.
With this change, all tests pass with both old and new versions of
screen.
Put the code that instructs vim to write its buffer to a temporary file
and then reads that file into a python string into the VimInterface
class. This will allow that to be done by code outside of tests.
Create classes for interacting with vim, a base class with common
methods, a class for interacting via screen, and one for interacting on
Windows.
At startup time an instance of one of these classes is created, and that
object is passed to all of the tests instead of the session.
I haven't been able to get UltiSnips working in vim on Windows to really
test this, but I have verified that vim interactions still work.
Don't warn about missing python support if the UltiSnipsNoPythonWarning
variable is defined. This allows users to use a common set of vim
configuration files across a range of systems, even if some of them do
not have python support compiled into vim.
Define a dummy version of the UltiSnips_FileTypeChanged function before
checking for python support. If that function isn't defined, the
autocommand defined in ftdetect/UltiSnips.vim will cause an error any
time a new file is opened. That autocommand is setup before the
function is defined, so we can't setup the autocommand only when the
function exists.
Commit 13331a8 added code to show the current line after insertions, but
later changes caused that to be called too soon. This left folds
created by a snippet closed, and the cursor at the end of the insertion.
