How do I make netrw behave with respects to cycling through buffers with :bprevious/:bnext

Question

I have my vim setup according to "Solution #1: Replicating Tabs with Buffers" on this site buffers-vs-tabs with the vim-airline plugin.

If I open numerous files in buffer 'tabs' :bprevious/:bnext just cycles through them great (and wrap when you get to the end of the 'tabs').

However, as soon as I attempt to use netrw by calling vim on a directory all of the sudden things start misbehaving.

For example, if I execute vim on a directory (vim .) and use netrw to drill down a directory hierarchy and hit Enter to open a file, it opens in a new buffer 'tab'. If I do :bprevious, it goes back to the netrw explorer. If I open another file with the explorer, it opens yet another buffer 'tab' to the right of the first file. :bprevious brings me back to netrw, not the file buffer to the left of the of the most recently opened file. Also when getting back to the file explorer, if I do another :bprevious, the cursor just jumps to the top of the netrw window and then doesn't move again with repeated :bprevious. Note that during this scenario the netrw is showing up as a buffer 'tab' in the tabline but not highlighted like files. Also note that the NetrwTreeListing 'count' on the bottom keeps incrementing.

Alternatively, if I execute vim without a directory and just use ctrlp to open some files and then use :Ex, A) it does not create a buffer 'tab', it simply displays a buffer/window with the netrw listing and I can open another file and it pops up as the leftmost buffer tab and :b(previous|next) works fine.

In either case :ls! shows a ton of NetrwTreeListing buffers.

I removed vim-vinegar to make sure it was not due to that and there wasn't really any change but the '-' feature of vim-vinegar does expose this issue as well.

Note: I apologize for poor terminology with regards to tabs/buffers/windows, but hopefully my explanation makes sense.

EDIT: Things get slightly better if I remove this from my .vimrc:

let g:netrw_liststyle=3

Sometimes I still get 'stuck' at the file explorer and :bprevious stays still.

Answer 1

So this has to do with the fact that:

vim .

Opens the current directory into a netrw buffer that is not unlisted. This is what causes odd behavior with :bp/:bn. If I :bdelete 1 soon as I open vim on a directory, then I don't have this issue for the rest of the session.

Alternatively:

vim +':Ex'

Does effectively the same thing but with the netrw buffer being unlisted.

I can use an alias to work around this.

But is there way to cause the default behavior of running vim on a directory to open an unlisted netrw buffer?

EDIT for more context:

So there are two issues:

A) treestyle netrw (style 3) is full of issues/bugs so I've given up on it.

B) Even with style 0, there is the issue of vim . opening the current directory and :ls! would show:

:ls! 1 h "~/gitworkspace/temp" line 1 2u%a- "[No Name]" line 1

Note that the first buffer is not unlisted like it should be.

I've come to find that it is due to set hidden in my vimrc. Unfortunately my vim workflow requires being able to edit a buffer and not write it before hopping around to another so I'm unwilling to give that setting up. Apparently netrw does not play well with that setting.

Answer 2

as soon as I attempt to use netrw by calling vim on a directory all of the sudden things start misbehaving.

had a similar a problem here, and at least over here, it seemed that the problem was that Netrw was also in the buffer list. In order to avoid that, I'm opening Netrw with:

nnoremap <leader>ff :20Lexplore<CR>

This way, Netrw won't be added to the buffer list that I'm actually making use of.

Also added this line:

let g:netrw_browse_split = 4

This will make sure that the files won't be opened in the same split where Netrw is.

Should also add that I haven't had problem with the tree style you mentioned. In fact, here is whole block (used in init.vim):

 nnoremap <leader>ff :20Lexplore<CR>
 let g:netrw_liststyle = 3
 let g:netrw_banner = 0
 let g:netrw_browse_split = 4
 let g:netrw_altv = 1

Since you've mentioned "behavior", you are probably looking for a better workflow. One thing that I had problem with was the fact that closing a buffer and/or a split would destroy how the layout (of splits and vertical splits, each one with its own buffers). So far, the problem was solved with to two mappings:

1 - for ':q' (which is used to quit splits, but mainly to quit Netrw when I'm done with it)

nnoremap <C-S>a :q<CR>

2 - and another one to delete the buffer, but still keeping the layout.

nnoremap <C-A>s :bp<CR>:bd#<CR>

This last mapping will change to the previous buffer (':bp') and close the alternate buffer (':bd#') which - in this case - is the one that I really need to close.

Since I did these changes to my workflow, I haven't experienced the problem you have. But I'm not sure what exactely was responsible for that change.