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
- Allow disabling displaying the search term.
- Allow setting the length for truncating the search term.
- Fix inconsistent status format for timed out:
No space between search term and counts.
Refactor s:get_hunks_coc() so that parsing the hunk status can be reused
by s:get_hunks_gitsigns().
Reorder s:get_hunks_coc() for consistent ordering with related code.
Give gitsigns.nvim priority over coc-git when selecting b:source_func in
hunks#get_raw_hunks().
as per https://github.com/tpope/vim-fugitive/issues/2034
This also fixes an issue that is shown in older Vims (pre 7.4.1711)
since those versions did not correctly catch exceptions while evaluating
the statusline.
closes#2566
Not marking the end makes the rest of line (after the close button) also clickable and react as if the close button was clicked. That is very confusing and incorrect behavior.
