E1513: Cannot switch buffer. 'winfixbuf' is enabled

[MaxGyver83]

Since my latest vim-fugitive upgrade, I get this error when I start vim directly with fugitive:

Error detected while processing command line:
E1513: Cannot switch buffer. 'winfixbuf' is enabled

I'm starting vim using this alias (to prevent a split screen with an additional empty buffer):

alias vg='nvim +G +"silent %bd|e#" +"norm gU"'

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?

[tpope]

I think you want nvim +"Gedit :" +"norm gU"?

[MaxGyver83]

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?

[tpope]

Look into wincmd o.

[MaxGyver83]

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"

[tpope]

Looks like this is sufficient to trigger an extra split at startup:

vim +'set winfixbuf'

@ColinKennedy does this seem like a bug to you?

2276 (cc @tom-anders) is similar, creating a duplicate window, but not at startup.

[ColinKennedy]

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.

[ColinKennedy]

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

[ColinKennedy]

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

[tpope]

I can't reproduce on a fresh Vim build. @MaxGyver83, might want to give it another try.

[MaxGyver83]

I'll try (tomorrow, CET).

[MaxGyver83]

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

[MaxGyver83]

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

[tpope]

Yeah looks like I can still reproduce on NVIM v0.10.0-dev-2688+g31a15fb2a-Homebrew.

[ColinKennedy]

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

[tpope]

I can reproduce with nvim --clean but not nvim -u NONE. This suggests it is triggered by a built-in runtime file.

[tpope]

It's s:VimEnter() in netrwPlugin.vim.

[ColinKennedy]

That explains a lot in that case. Alright, I'll double check those repro steps and try a fix in the next few days

[tpope]

This command causes a winfixbuf window to split:

windo echo 'no-op'

[ColinKennedy]

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!

[Shane-XB-Qian]

https://github.com/vim/vim/pull/14142

[seandewar]

vim/vim#14142

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: