As of version 0.12 of Neovim, the replaced API call is being deprecated. From 0.11.0 there is already a “deprecation warning” in place.
This patch corrects that by using the new API call.
The special argument --no-optional-lock applies to the main git command,
and not to the git subcommand `git status`. So move it there, to prevent
an error with git.
closes#2651
Signed-off-by: Christian Brabandt <cb@256bit.org>
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:
27344d6a6c
There's also GIT_OPTIONAL_LOCKS=0 environment variable, but that
requires more infra work.
This function simply returns the current tabnumber followed by the
number of buffers in the current tabpage.
The previous one either was broken long ago or did not work as expected.
fixes#2616
Make sure, that the second argument is actually a number and not a list.
Note: even when fixing this, the tabpage still shows some strange output
e.g. currently
1 1.%{len(tabpagebuflist(1))}
In a vim window. Not sure, why Vim does no longer evaluate those %{..}
sections. Perhaps some change in Vim?
closes#2616
IK
get-me-power
wzy
Dionisio E Alonso
Christian Brabandt
Lars Hansen
Nobuhiro MIKI
Ingo Meyer
Billy Chamberlain
David Briscoe
Sweidan Omár
eximus
get-me-power
Simon Truscott
Artem Minyaylov