When switching buffers during the handling of the BufDelete event the
saved buffer number of the last alternate buffer will change, so we have
to save a local copy to be able to properly unset the 'tagbar_ignore'
buffer variable.
When opening the Tagbar window the window numbers can change so that
restoring the window history is not possible. Use the new window ID
functionality if it is available to make that possible.
When we have to go to the Tagbar window to update it the knowledge of
the previous window to the one we're coming from gets lost. Save it
before switching windows so we can restore it after returning from the
Tagbar window.
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.
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().
a:ctags_bin calls a batch file that uses %~dp0. Changes include:
- Enable ctags_args to be a list
- Changed default ctags_args to be a list to improve robustness of
s:EscapeCtagsCmd()
- Do not escape 0th argument of ctags_cmd for cmd.exe when it is not
necessary because otherwise batch files may not return expected value
for %~dp0
- Updated tagbar documentation about string and list value types for
ctags_args
See https://github.com/majutsushi/tagbar/issues/133
Since the window numbers can change when opening and closing windows
Tagbar so far has used bufwinnr() to find the right window to jump back
to. However, this fails if the same file is being displayed in more than
one window. Save a window-local variable instead to detect the correct
window to jump back to.
If a ctags-compatible program returns an error status code on a parsing
failure then it would never be run again on the same file, even if later
invocations would have returned normally (for example after fixing an
error in the current file). Therefore we need to execute the program on
updates as usual, but do not repeat error messages if the previous run
already did.
We only need to reset '0 mark when our tagbar window is the last one,
otherwise, just quit the window and let the other window handle the
error that might happen on quiting Vim.
If there are other plugin windows open, close tagbar window and handle
over the control to the other window.
If the last file in the Vim's file arguments list has not been edited
yet, normal Vim's behavior would be quit on ':q!' or twice ':q'. As our
plugin window is the last window now, previously quiting on the file
window will not trigger the "more files" check, but our window does.
We'd better to behave the same. Currently, twice ':q' quiting would work,
but ':q!' not. There is no easy way to determine whether the command
being executed with a "!" or not, so this is a flaw now and we need
to come up a better solution someday, but it is a progress than before.
Changes requested by majutsushi.
Changed function to :TagbarTogglePause
Added documentation for function, including usage and defintion.
Changed autocommands_enable to autocommands_enabled.
tagbar#PauseAutocommands :TagbarPause
:TagbarPause pauses autocmds, effectively freezing Tagbar on the last
file. Useful for keeping a tag reference for a file open whilst working
in a different file.
