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.
