Fix "fatal: Unable to create '.git/index.lock': File exists." when doing
fugitive commands.
Since upgrading fugitive from fugitive@7c1f2ed to 5f0d280, I
occasionally hit this lock error when using `ZZ` to save and close the
fugitive rebase window.
I have no other windows or tabs open (nothing that might be invoking
git). I get the error around 1 in 5 attempts on a larger git repo and
less often on small repos (like vim-fugitive's repo).
However, I have airline and have the git branch name and dirty status in
my **statusline**. A minimal repro of just sensible, fugitive, and
vim-airline with no custom airline configuration produces the issue. If
I use `:AirlineToggle` to turn off the statusline, it seems to go away.
Airline uses fugitive to get the branch name (with `FugitiveHead()`) and
strip the `fugitive://` name from buffers (with `FugitiveReal()`).
I tried removing ShellCmdPost fugitiveline.vim and that *seems* to fix
it, but I don't understand why.
What makes more sense is that the dirty check is asynchronous and is
trying to check status when fugitive is trying to rebase. Because the
repo is large, it takes longer to get status (true for just running `git
status` too).
I have async enabled:
:echo g:airline#init#vim_async
1
tpope suggests using --no-optional-locks to solve:
https://github.com/tpope/vim-fugitive/issues/1624
That also appears to fix the issue.
This flag was introduced to git in 2017 which would make airline fail on
older gits:
https://github.com/git/git/commit/27344d6a6c8056664966e11acf674e5da6dd7ee3
There's also GIT_OPTIONAL_LOCKS=0 environment variable, but that
requires more infra work.
Fix NUL file created when opening a .po file.
Using -o NUL actually creates a file called NUL in the current
directory. Using /NUL doesn't create one in C:\ (the drive the file is
located on) or any visible drive.
Despite msgfmt being able to create the file NUL (which isn't supposed
to be allowed), it's difficult to delete NUL (windows explorer can't
handle it but WSL's unix rm can remove it).
Test
Open po file and see the same warnings as before, but no NUL file
created.
Using msgfmt.exe provided by git (installed via scoop).
Fix: a literal '0' appears after filename on older versions of vim-lsp.
0c8164b1b3 added support for showing lsp
progress, but didn't always explicitly return a value. Vim uses 0 as a
return value when none are supplied, so when used with an older version
of vim-lsp that doesn't have the progress feature a 0 appeared in the
statusline.
Fix#2062: restore g:airline_focuslost_inactive behaviour.
Only ignore focusgained events on Windows. If there are more problematic
platforms, we'll add them later.
Instead of ignoring the next x FocusGained events whenever we do call
system(), ignore them for the current second. That allows us to put a
hard limit on the duration of the ignore.
This seems like a much better solution than the previous one because it
also prevents ignore events from building up (s:focusgained_ignored was
often greater than 5).
Test (gvim 8.2.140 on Win10)
gvim.exe ~/.vim/bundle/airline/autoload/airline/extensions/branch.vim
:Gedit HEAD
check several parents and no regression of looping behaviour from #2053.
:let g:airline_focuslost_inactive = 1
:split
alt-tab several times and statusline is correctly dimmed and restored
each time.
closes#2029
airline#util#focusgain(1) was called too soon -- it's called before vim
loses focus and not after it gains focus. Instead, we ignore the next
FocusGained event.
Instead of requiring each version control plugin to modify airline to
show the current branch, provide a customization function we can check
instead.
Following the example of airline_theme_patch_func, you define the
variable like so:
let g:airline#extensions#branch#custom_head = 'david#svn#get_branch'
Custom functions should cache their value. They may need an autocmd to
invalidate their cache:
" Use a buffer-unique group name to prevent clearing autocmds for other
" buffers.
exec 'augroup svndavid-'. bufnr("%")
au!
autocmd BufWinLeave <buffer> unlet! b:svndavid_branch
augroup END
This change lets me integrate with vc.vim (I couldn't get VCSCommand
working for svn) or write my own thing for perforce.
Additionally, always load whole file and check for existence.
Instead of determining up front whether various scm plugins are
installed, check for them on use so they can be added after this script
is sourced.
This also mitigates the problem of checking for existence of autoload
functions (which are not loaded by exist()). Since we're checking
root-level functions, they're likely to be loaded once we're using any
part of the plugin.
David Briscoe