If the user had a hidden buffer and a recent version of Vim, the screen would
flicker every time the user typed. This was caused by a Vim bug.
On every key press, we end up calling GetUnsavedAndCurrentBufferData(), which
calls GetBufferOption( buffer_object, 'ft' ). If the buffer_object represents a
hidden buffer, Vim would flicker.
This would happen because we'd call "buffer_object.options[ 'ft' ]" in recent
versions of Vim, and that line of code causes Vim to flicker. I don't know why.
We're extracting the 'ft' value without going through buffer_object.options, and
that works just fine.
Fixes#669.
Now, "foobar.h" will be changed to insert "foo" if the text after the cursor is
"bar.h". This already worked for "foobar" and "bar", but the overlap search
would stop before a non-word character. This has now been resolved.
Previously we'd show a Python traceback if the user asked for a detailed
diagnostic in a file that wasn't supported by Clang (something written in Python
perhaps). Now we show an nice, far less scary message informing the user of
this.
Fixes#748.
Previously, we'd implicitly turn off future notices about unknown extra conf
files if we already raised one exception about it. This breaks when the user
ends up not receiving the "unknown extra conf, load?" message.
Now we only turn off the notice as a result of the user saying "don't load this"
so that if the first request fails to reach them, they'll get a second (and
third etc) request about it.
Fixes#615
We pass shell=True to Popen so that OmniSharp is not started inside a
new visible window under Windows. And since we use shell=True, we pass
the command to execute as a string, as recommended by Python's docs
(also, it won't work when passed as a sequence anyway :) ).
This can happen when the user inserts a candidate string like "operator[]" which
doesn't end with an identifier char. A very obscure bug, but a bug nonetheless.
When loading the Omnisharp server, YCM tries to find a suitable solution
file to feed it. Instead of giving up when finding multiple solution
files, it now tries to find one named like the edited files' folder at
the solution level, e.g. if we have bla/Project.sln and we are editing
bla/Project/Folder/Whatever/File.cs, we use bla/Project.sln.
This option existed so that the user can tweak it if they found the default idle
timeout too short, for instance if they leave their machine on over the weekend.
This use case is now covered by the new YcmdKeepalive system that pings ycmd
every 10 minutes as long as Vim is running. This prevents ycmd shutting down if
one leaves their Vim instance alone for a long time.
Thus the old option is useless now; ycmd now shuts down after 3 hours of
inactivity, which should only ever happen when its corresponding Vim instance
has shut down abnormally.
We don't want to send a unicode string to the user's ycm_extra_conf.py file.
This should fix problems with sending the filename to YCM's CompilationDatabase
API.
By default, a ThreadPoolExecutor will wait at Python interpreter shutdown for
all the threads to stop by themselves before letting the interpreter shut down.
We don't want that for the network requests thread pool, it causes a shutdown
latency if there are outstanding requests. Killing the threads in our pool is
perfectly safe so we can avoid the latency by introducing an
UnsafeThreadPoolExecutor.
[vimwiki][] has a markdown-like syntax, which doesn't bode well with YCM
(flickering "pattern not found" messages, performance hits with long prose).
[vimwiki]: https://github.com/vimwiki/vimwiki
