coc-explorer
coc-explorer copied to clipboard
[BUG?] When closing one of two opened files coc explorer is the only buffer visible
Describe the bug
When opening vim in a project, open the explorer. Then open one file. Then go to the explorer and open another file. When closing the first file with :bd!
the explorer is the only buffer that shows. However I would expect the first open file to appear next to the explorer instead.
Result from CocInfo
## versions
vim version: NVIM v0.7.0
node version: v18.1.0
coc.nvim version: 0.0.80-fb8bcf53 2022-05-13 21:15:23 +0800
coc.nvim directory: /home/user/.config/nvim/plugged/coc.nvim
term: st-256color
platform: linux
## Log of coc.nvim
2022-05-14T06:00:42.272 INFO (pid:273662) [plugin] - coc.nvim initialized with node: v18.1.0 after 309ms
2022-05-14T06:00:43.597 INFO (pid:273662) [attach] - receive notification: showInfo []
Steps to reproduce Steps to reproduce the behavior:
- execute
nvim
-
:CocExplorer
- Open two files from the explorer
- Close the first file using "bd!"
- Only explorer is visible although there is the other file still open in a buffer
Expected behavior
I would expect to get back to the first file appearing next to the explorer instead to the explorer only after closing the second opened file.
Screenshots
no screenshots
Additional context
I am using the explorer version 0.24.1
. In:
NVIM v0.7.0
Build type: Release
LuaJIT 2.1.0-beta3
Übersetzt von builduser
Features: +acl +iconv +tui
See ":help feature-compile"
System-vimrc-Datei: "$VIM/sysinit.vim"
Voreinstellung für $VIM: "/usr/share/nvim"
Run :checkhealth for more info
How did you open the two files? I tried to open two files with E but can't reproduce your issue
I have opened them from the explorer by hitting enter.
I am currently experimenting. I removed all vim plug installed plugins and all config exept for a minimal one. Then I still have that behaviour. Next thing would be to get rid of all the coc installed plugins as well. I will report on my findings
Hm. Ok that happens to me even when I run everything with a minimal configuration. I only have coc installed and a color scheme. Then in coc I have everything default config and only coc-explorer installed.
Here the behaviour shown with images.
-
Open vim and open explorer in project folder
-
Open first file. It appears on the right hand side as expected
- Open second file it appears on the right hand side as expected
- Close the second file. Then I end up in the explorer instead of having the still open, last active buffer on the right hand side shown.
- So this is what I actually would expect when closing the second file:
I think I got your mean, but explorer does not consider overriding the default behavior of vim / neovim.
In my opinion, The management of the buffer and window should be left to the user. if the explorer also automatically switches buffer when executing :bd!
, this is too much of a change to vim's default behavior, and it would be better to let the user implement the relevant stuff themselves.
OK thanks for the explanation. That makes sense. So I try to follow your advice for now and check if I can figure out a way to implement this into my vim configuration. I can imagine that others might also be interested in this. I can share my solution here in case I can come up with something.
Part of the solution is
:bp\|bd #<CR>
It first goes back to the last buffer and then deletes the previos buffer. However one need to bake this into some conditional logic as it might not be desired behaviour in all buffers. E.g. when you like I do have mapped out the <leader>
bd to close your buffers with bd!
and now change this to the above mapping. You would get e.g. when you close the explorer buffer the small split filled with the last active buffer, which is undesired.
I was experimenting with autocommands on this. Without much success so far to change the mapping when entering coc explorer e.g.
I somehow gave up on it. However I also discovered this plugin here which brings exactly that behavior qpkorr/vim-bufkill
I have recently started using moll/vim-bbye
to solve this, so far everything seems fine.