Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG?] When closing one of two opened files coc explorer is the only buffer visible #525

Open
cpfaff opened this issue May 14, 2022 · 11 comments
Labels
discuss enhancement New feature or request question Further information is requested

Comments

@cpfaff
Copy link

cpfaff commented May 14, 2022

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:

  1. execute nvim
  2. :CocExplorer
  3. Open two files from the explorer
  4. Close the first file using "bd!"
  5. 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
@cpfaff cpfaff added the bug Something isn't working label May 14, 2022
@cpfaff cpfaff changed the title [BUG] [BUG?] When closing one of two opened files coc explorer is the only buffer visible May 14, 2022
@weirongxu
Copy link
Owner

weirongxu commented May 14, 2022

How did you open the two files? I tried to open two files with E but can't reproduce your issue

@cpfaff
Copy link
Author

cpfaff commented May 14, 2022

I have opened them from the explorer by hitting enter.

@cpfaff
Copy link
Author

cpfaff commented May 14, 2022

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

@cpfaff
Copy link
Author

cpfaff commented May 14, 2022

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.

@cpfaff
Copy link
Author

cpfaff commented May 15, 2022

Here the behaviour shown with images.

  • Open vim and open explorer in project folder
    2022-05-15-064951_1906x1004_scrot

  • Open first file. It appears on the right hand side as expected

2022-05-15-065030_1920x999_scrot

  • Open second file it appears on the right hand side as expected

2022-05-15-065124_1911x998_scrot

  • 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.

2022-05-15-065201_1910x996_scrot

  • So this is what I actually would expect when closing the second file:

2022-05-15-065030_1920x999_scrot

@weirongxu
Copy link
Owner

weirongxu commented May 15, 2022

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.

@weirongxu weirongxu added enhancement New feature or request question Further information is requested discuss and removed bug Something isn't working labels May 15, 2022
@cpfaff
Copy link
Author

cpfaff commented May 15, 2022

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.

@cpfaff
Copy link
Author

cpfaff commented May 15, 2022

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.

@cpfaff
Copy link
Author

cpfaff commented May 15, 2022

I was experimenting with autocommands on this. Without much success so far to change the mapping when entering coc explorer e.g.

@cpfaff
Copy link
Author

cpfaff commented Jun 1, 2022

I somehow gave up on it. However I also discovered this plugin here which brings exactly that behavior qpkorr/vim-bufkill

@andersoncustodio
Copy link

I have recently started using moll/vim-bbye to solve this, so far everything seems fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants