Closed MaxGyver83 closed 5 months ago
I think you want nvim +"Gedit :" +"norm gU"
?
I think you want
nvim +"Gedit :" +"norm gU"
?
When I use this, it looks good at first. But then I look at a diff with dd
. After closing both buffers, I end up with an empty buffer. How can I keep the git status open while looking at diffs?
Look into wincmd o
.
Thanks for the hint. Running this manually works fine:
nvim
:G
:wincmd o
gU
But when I run this as a single command, I end up with two git status windows:
nvim +G +"wincmd o" +"norm gU"
Looks like this is sufficient to trigger an extra split at startup:
vim +'set winfixbuf'
@ColinKennedy does this seem like a bug to you?
Short answer is yes, that's definitely unintended. I'll make a separate issue for that.
I think I've also seen that bug but in a different scenario. In my original PR when you do :cnext
and the previous windows is a 'winfixbuf'
, :cnext
was meant to pass over that window and choose another which is 'nowinfixbuf'
instead. If there was no alternative 'nowinfixbuf'
window, create a split. But recently I tried doing this on vim master and it create a split even when there was a suitable fallback window. Either my original logic was faulty or it could have changed after https://github.com/vim/vim/pull/14142.
I have a feeling it's the same bug, manifesting in different scenarios.
I've been working on a few winfixbuf bug fixes but wanted to circle back to this comment
Looks like this is sufficient to trigger an extra split at startup:
vim +'set winfixbuf'
I'm unable to reproduce this on the latest Vim and Neovim. See recording.
Neovim commit: 011585f35fee83c27e6db91a4ed0feff362efa75 Vim commit: 51c94b650632f17f23efba1de928442d3e859b7d
https://github.com/tpope/vim-fugitive/assets/10103049/8eb37690-dd1e-48e0-93f6-6f232d2cce5a
If this still happening it'd be good to get a specific repro so I can log an issue in GitHub and get a fix out. For now I'll fix the issues that I have repros for
But recently I tried doing this on vim master and it create a split even when there was a suitable fallback window.
I also can't reproduce this anymore. I'll keep a lookout and fix it if I can get a reproduction back. For now things are fine
I can't reproduce on a fresh Vim build. @MaxGyver83, might want to give it another try.
I'll try (tomorrow, CET).
This command still results in a split screen for me:
nvim-v0.10.0-dev-2685.appimage +'set winfixbuf'
I'm using today's nightly release as an AppImage here:
NVIM v0.10.0-dev-2685+g02d00cf3e
Build type: RelWithDebInfo
LuaJIT 2.1.1710088188
This command opens a single buffer/window:
nvim-v0.10.0-dev-2685.appimage +'set winfixbuf' -u NONE
So I think it's about my .vimrc
. I have tried again with a minimal (=empty) vimrc
and still got a split screen. Same result using /dev/null
as vimrc
:
nvim-v0.10.0-dev-2685.appimage +'set winfixbuf' -u /dev/null
Yeah looks like I can still reproduce on NVIM v0.10.0-dev-2688+g31a15fb2a-Homebrew
.
Let's summarize here for a moment.
I cannot reproduce it with neovim or vim's latest master commit
@MaxGyver83 also cannot reproduce it when including -u NONE
but with some other .vimrc
@tpope can reproduce it (unspecified if -u
is included)
Is that right?
I can try again with another install and see
I can reproduce with nvim --clean
but not nvim -u NONE
. This suggests it is triggered by a built-in runtime file.
It's s:VimEnter()
in netrwPlugin.vim
.
That explains a lot in that case. Alright, I'll double check those repro steps and try a fix in the next few days
This command causes a winfixbuf
window to split:
windo echo 'no-op'
Reproduced with XDG_CONFIG_HOME=/tmp/somewhere/else vim +'set winfixbuf'
and XDG_CONFIG_HOME=/tmp/somewhere/else nvim +'set winfixbuf'
Thanks to that windo
clue, I think the problem comes from https://github.com/vim/vim/blob/769eb2d0c3614f9ea6fffa82329558f1a4af384f/src/ex_cmds2.c#L478
I've started a Vim issue over at https://github.com/vim/vim/issues/14301. Thank you for finding this and bringing it up!
Echoing this here for clarity: that PR did not introduce this behaviour. It's reproducible since the original 'winfixbuf'
v9.1.0147 patch from vim/vim#13903; you can see the relevant code here...
However, while working on my PR, I did notice that the :windo
behaviour may be problematic here, but chose not to address it at the time as I wasn't sure what it's potential impact would be.
I don't mind addressing it at some point, but my availability is limited in the next few weeks. Feel free to work on this @ColinKennedy if you're interested. :+1:
Since my latest vim-fugitive upgrade, I get this error when I start vim directly with fugitive:
I'm starting vim using this alias (to prevent a split screen with an additional empty buffer):
Last week, there were three commits related to
winfixbuf
. Is this a bug in the plugin? Or should I update my alias? If yes, how?