The QuitPre autocommand was introduced in Vim version 7.3.544. If Vim is
older than this then don't use the HandleOnlyWindow() functionality, so
in the case of closing the last window in a tab a user will have to
close the Tagbar window themselves.
This commit should (hopefully) finally fix the case of users calling
':bdelete/:bwipeout' or ':quit' while Tagbar is open and just do the
right thing. See commit e4cfe8a for a more thorough description of how
it's supposed to work.
When a window that is displaying a normal file gets closed with a :quit,
:bdelete or other command, Tagbar may end up as the only visible window
left, which isn't very useful. Previously Tagbar would just quit in such
a situation (unless there was more than one tab), but that is rather
non-intuitive.
The change in this commit introduces a mechanism that should hopefully
handle such a case properly based on which command was executed, and do
exactly what a user would expect:
- In the ':quit' case, it will close the current tabpage including
Tagbar unless it was the only tabpage, in which case it will quit Vim.
- In the ':bdelete/:bwipeout' case, it will delete the Tagbar buffer and
then reopen Tagbar once the buffer that Vim switched to is being
displayed.
This commit fixes tagbar compatibility issues with the
[universal-ctags](/universal-ctags/ctags), which is the most active and
consistently updated fork of the old exuberant ctags.
Failing to suppress output can cause problems in some environments,
especially if the shell command fails or does something else spooky.
Example where failing to suppress the shell command causes issues with
[vim-airline](https://github.com/bling/vim-airline) with the tagbar
extension enabled:
Here's another example:
Both were taken using uxterm in Linux.
If the runtimepath has been set incorrectly and the autoload file is
getting loaded by something, then the code won't be able to load the
"plugin" file. Print a warning message and stop loading the file instead
of throwing lots of errors.
