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.
Instead of using 'echoerr' and essentially breaking the plugin after
that problems are now reported as warnings with 'echomsg'. They will
also only be shown once for a particular problem.
The current tagbar_autoclose state will be displayed in the statusline.
Also change the "hide nonpublic" flag to "v" to match the mapping and
properly document the statusline flags.
If someone already has a function that includes "JumpToTag" in its name
then the current method of detecting whether mappings should be
initialized would fail. Use a buffer-local variable instead.
If 'hidden' is not set then BufUnload is called every time a buffer
would get hidden, removing the fileinfo. This causes unnecessary ctags
processing of files.
The current pause functionality simply removes all the autocommands to
stop updating Tagbar. This has the problem that at the moment the
statusline functions immediately restore the commands so pausing doesn't
work, but even if that didn't happen it would stop the statusline
functionality from working which is not desirable. The solution is to
have a reference to the paused file which will get used by the Tagbar
window, but not the statusline functions.
Certain quickfix-commands like vimgrep have to load all searched files
into Vim and will execute the BufReadPost autocmd for all of them. Since
Tagbar doesn't need to generate tags for those files pause processing
while the command is running.
There doesn't seem to be a better way to find out whether vimgrep is
running than to set a temporary variable with the QuickFixCmdPre/Post
autocmds, see also
https://groups.google.com/forum/#!topic/vim_use/sUj5MFGmwD8
Closing Tagbar with :q instead of the provided commands and mappings
would bypass the Vim application window shrinking logic. Install an
autocommand that checks for this situation.
This prevents files being processed twice unnecessarily, once for
FileType and once for BufReadPost. All cases where BufReadPost is called
without FileType should be covered by the checks in AutoUpdate().
