I'm pretty new to Vim, but I'm still clinging on to the concept of a persistent interface element that gives me information about the buffers that I have open.
I haven't been able to develop that mental facilities to keep track of what's happening with all my buffers in my own head yet, so the idea is to have a persistent bufexplorer window that refreshes itself with some mechanism (that I hope to create myself).
If I delete a buffer outside of bufExplorer after opening bufExplorer, there is no apparent way to refresh it. I've tried r r, and a few other commands but nothing works. If I do :bufExplorer in the bufExplorer window i get a "Escaped\nWHAT THE 1\nWHAT THE 2\n".
Any help in creating a mechanism to refresh the buffer list would be awesome. I'm completely new to Vim scripting but can learn.

Thanks

Love this plugin, and use it regularly.

Noticed with neovim terminal, cannot currently use this plugin to delete the terminal buffer.

Please see my explanation here.

using d , am asked to add ! to override
using D , am also asked for override

When doing :bd! from command line, this kills the terminal buffer no questions asked.

is there any way to augment the d and D commands so they take a ! ?
Would you consider adding such support?

Thanks again for awesome plugin.

Every now and then I do a :windo diffthis to compare a couple of buffers, and then I forget to turn the diff mode off when switch away to a different file to investigate something (jumping to tags etc.). Then it becomes rather difficult to find the buffer I was comparing with.

Wouldn't it be nice if bufexplorer could indicate which buffers have &diff mode set with a sigil of some kind, next to the '%h-' thingies?

I'm using a really simple plugin called restore_session that automatically calls mkview when saving a buffer or exiting vim, and then calls silent loadview when entering the buffer. This allows you to return to the exact previous cursor location of a file when you re-enter vim, along with restoring some other things like folds. However, using this plugin breaks the MRU sort in BufExplorer, because of this line:

autocmd SessionLoadPost * call s:Reset()

Every time loadview gets called (which happens whenever you enter a buffer), Reset() is called, which re-initializes the MRU list. I'm able to workaround the issue by commenting out the above line. However, I can see from the changelog that the line in question was originally added to fix a bug related to MRU sort after loading sessions. Oddly, it introduces a bug for me when loading sessions, but I'm assuming there's some other use-case that breaks without this line. I'm not sure how/if you can fix both problems at the same time, but I'll let you figure that out :)

hi , when i list buffers and want to open somebuffer in new tab with key t, show this error .
my version is
" Version number
41 let g:bufexplorer_version = "7.2.8"

Hello jlanzarotta!
How can i select and open buffer in previous window after using command :BufExplorerHorizontalSplit

Suppose I have opened bufexplorer (:BufExplore), and I press <enter> to open the buffer under the cursor. When the buffer opens, :buffers shows that the bufexplorer buffer is still present. Is there a way to automatically remove the bufexplorer buffer when opening a new buffer?

Hello,

I'm using mksession to create and restore sessions from Vim and I noticed that after a session is loaded the first buffer becomes last. This is weird and the only way I can fix it is to load all other buffer into the list. Here's a demo of the problem. I'm using the normal sorting behavior.

I've noticed (consistently) that if I do <leader>bv and then use t to open a buffer in a new tab, when I come back to the tab I opened bufexplorer in, the original file (the one that was active when I typed <leader>bv is now open in both left and right splits.

This may be a misunderstanding on my part, if so please set me straight. Or perhaps it is a peculiarity of my vim configuration.

With g:bufExplorerFindActive enabled (1), open FILE1 in window 1 and FILE2 in window 2, both in the same tab (i.e., using a 'split').

From window 1, invoke bufexplorer and select the buffer for FILE2.

I expected the focus to change to window 2, instead the buffer for FILE2 is loaded into window 1 and now both window 1 and window 2 are showing FILE2.

Is that expected behaviour?
MV

Sometimes user want to remap the default map, but map <buffer> xxx :call <SID>foobar()<CR> make it very hard. Perhaps use map <buffer> xxx :call bufexplore#foobar()<CR> to replace it will be better?

perhaps I'm unaware of the convention that we refer to by it's default, but I believe it's better to make the distinction.

Steps I took:

1. in a vim window, open file1, file2 and file3 in separate tabs.
2. close the tab for file3, go to the tab for file2
3. use <leader>bv to open bufexplore in a vertical split.
4. now the file3 entry is in the list, navigate to that, and hit t to open it in a new tab.

I assume this would get me back to the state after step 1. However if I navigate to the tab for file2 (where I launched bufexplore), I saw the same file opened twice in a vertical split, like below:

-----------------------------------------------------
|  file 2 contents       |      file 2 contents    |
|                        |                         |
|                        |                         |
-----------------------------------------------------

I think this is rather counter-intuitive. Is there any easy way of getting around this?
I'm using vim 8.1.

Thanks!

I've mapped <leader>\bs to <c-b>. Once the minibufexplorer window is opened. Could (:BufExplorer) execute a toggle instead?

So if minibufexplorer is already opened, it just closes it.

Ideally, Pressing <c-b> the first time, will open the plugin. Pressing a second time will close it.

I don't know if this is the right plugin to do this, or even if Vim CAN do it, but I would find it extremely useful to be able to mix tabs and buffers together in such a way that each tab has its own list of buffers to go through. Example:

/  1. Tab01  /  2. Tab02   /  3. Tab03  /
/  1. Buf1   /  1. Buf2    /  1. Buf3   /
/  2. Buf4   /  2. Buf5    /            /
/            /  3. Buf6    /            /

Each column of buffers are linked, and able to navigate up/down the list with :bn/:bp. If you get to the bottom of the buffer microlist, wrap back to the top buffer.
This would be awesome, and any pointers towards where or how I could achieve this functionality would be greatly appreciated.

Great work on the plugin btw, thanks.

Hello.

Subject pretty much describes the problem. Here's how you can reproduce it:

• Open .vimrc.
• Call ToggleBufExplorer. Now BufExplorer window is opened. Contents are (on my setup):

  1 %a    .vimrc . line 59

• Close BufExplorer using ToggleBufExplorer.
• Call ToggleBufExplorer again. Again BufExplorer window is opened. Contents are (on my setup):

  2 # -   [BufExplorer] . line 1
  1 %a    .vimrc        . line 59

As you can see BufExplorer buffer is shown in the list of buffers, however display of unlisted buffers is not enabled in my config:

let g:bufExplorerDefaultHelp = 0
let g:bufExplorerShowRelativePath = 1
let g:bufExplorerSortBy = 'mru'

Please fix.

Hello: I really like this plugin -- thank you! However, I often inadvertently delete buffers with which I am actively working, and have to:

• remember what it was I was working on
• search for/reopen them (:browse oldfiles is not much help: too unwieldly)

Here is a workaround, to disable the d: delete buffer and D: wipe buffer menu items / commands.

• Back up bufexplorer.vim --> bufexplorer.vim.original
• comment-out ( " ) these six lines in bufexplorer.vim:

MapKeys function (line ~498+):

" nnoremap <script> <silent> <nowait> <buffer> d             :call <SID>RemoveBuffer("delete")<CR>
" xnoremap <script> <silent> <nowait> <buffer> d             :call <SID>RemoveBuffer("delete")<CR>
" nnoremap <script> <silent> <nowait> <buffer> D             :call <SID>RemoveBuffer("wipe")<CR>
" xnoremap <script> <silent> <nowait> <buffer> D             :call <SID>RemoveBuffer("wipe")<CR>

CreateHelp function (line ~619+):

    " call add(header, '" d : delete buffer')
    " call add(header, '" D : wipe buffer')

Restart (neo)vim. :-)

I'm getting an error message (see below) intermittently when I close BufExplorer. It occur only after I've wiped one or more buffers, using the D key, but not every time.

Error detected while processing function <SNR>19_SelectBuffer..<SNR>19_Close:
line 17:
E86: Buffer 14 does not exist

I will do some investigating on my own, including tracking down the exact steps needed to reproduce the error.

Reproduce steps:

• $ nvim open neovim
• :term open terminal buffer
• :e test open normal buffer
• :BufExplorer show buffer list
• j<CR> switch back to terminal buffer
• The whole neovim quit.

Environment:

• iTerm2 on macosx
• NVIM v0.3.4
• bufexplorer git head

Hi,

I am using zsh shell on CentOS release 6.5. I install bufexplorer plugin using vundle. I am able to list the buffers using \bs and also able to move to other buffers using up/down arrow. But when i press "ENTERY" on a particular buffer, it does not open that file instead it just goes to next line. It use to work, but suddenly i am seeing this issue. Not sure if i am missing any settings.

Uday

Is it possible to have the state of the bufexplorer to be saved during quitting, so I can have the same set of buffers open on the next vim start?

This is a reissue of pull request #22, after I'd mistakenly deleted by branch.

I added the following things to toggle the BufExplorer list on and off.

the command :ToggleBufExplorer
the map <Leader>bt, and
the function ToggleBufExplorer()
The function works by simply calling the BufExplorer() or s:Close() function, depending on the current state of BufExplorer. Now one can easily see which buffers are open (with a mapped function key, ideally), and then easily close the buffer list with the same key.

I believe this pull request will satisfy the request in Issue #3.

Autochdir works, until one of the buffers is changed. After the change, pwd has been reset to some initial value (seem to be the value pwd had when vim was started).

Using MacVim 7.4 (72) with latest bufexplorer (installed via Vundler from this repo).

Steps to reproduce:

1. Open three buffers (lets call them buf1.txt, buf2.txt and buf3.txt)
2. <leader>\be (to open bufexplorer)
3. I don't think sort order matters, but for arguments sake, sort by mru, eg.

3 %a buf3.txt
2 #h buf2.txt
1  h buf1.txt

1. Position cursor on top buffer (buf3.txt)
2. <shift-V> (to enter visual line mode)
3. j (to go down one line)
4. d (to delete the two selected buffers)

Expected results:

Buffers buf3.txt and buf2.txt should be deleted, leaving just buf1.txt

Actual results:

Buffers buf3.txt and buf1.txt are deleted, leaving just buf2.txt

Tried all different sort orders, but in all cases it seems to delete the first and last buffer and keep the middle one, instead of deleting the first and middle and keeping the last.

Hello.

After upgrade from bufexplorer 7.4.2 to 7.4.5 I now have the following message printed on vim startup:

Error detected while processing /usr/share/vim/vimfiles/plugin/bufexplorer.vim:
line   66:
E492: Not an editor command: ^M
line   69:
E15: Invalid expression: exists("g:bufexplorer_version") || &cp^M
line 1217:
E171: Missing :endif

Please fix.

$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 14 2014 10:53:10)
Included patches: 1-475
Modified by Gentoo-7.4.475
Compiled by coacher@Photon
Huge version without GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
-balloon_eval    +float           +mouse_urxvt     -tag_any_white
-browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
+clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      -toolbar
+cmdline_compl   +insert_expand   -perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python          +viminfo
-cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con      +lua             +rightleft       +windows
+diff            +menu            -ruby            +writebackup
+digraphs        +mksession       +scrollbind      +X11
-dnd             +modify_fname    +signs           +xfontset
-ebcdic          +mouse           +smartindent     -xim
+emacs_tags      -mouseshape      -sniff           +xsmp_interact
+eval            +mouse_dec       +startuptime     +xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "/etc/vim/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/share/vim"
Compilation: x86_64-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -march=corei7 -mtune=corei7 -msse4.2 -mfpmath=sse -fomit-frame-pointer -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: x86_64-pc-linux-gnu-gcc   -Wl,-O1 -L/usr/local/lib -Wl,--as-needed -o vim    -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -lncurses -lelf -lnsl   -ldl  -L/usr/lib -llua  -L/usr/lib64/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic

Looking at the code, I think execute "999tab split +buffer" . _bufNbr should be changed to execute "tab split +buffer" . _bufNbr. Currently opening a buffer in a new tab results in "E16: Invalid range: 999tab split +buffer "

When execute "999tab split +bufferN
Fail:
E16: Invalid range

Hi Jeff

Thanks for creating this amazing plugin. I have recently been having this issue. I was initially confused as to what is causing this, as this tends to be intermittent.. but now after searching through all my vim plugins.. it seems the BEActivateBuffer occurs in BuffExplorer.

Any idea why this is happening.. and what can be done to fix this?

BufExplorer will create extra [No Name] buffers under the following scenario:

1. Start vim with no buffers, or use :bd or BufExplorer to delete all the buffers.
2. Toggle BufExplorer repeatedly, using either of these commands:
   • :ToggleBufExplorer,...
   • :BufExplorer, q,...

It appears that the Close function is the cause, where it will create a new buffer if none exist.

Hi, please tag releases using git. This way people can easily see the newest release on github without browsing commit history.

OS: Linux / Ubuntu 16.04

I'm experiencing a delay of about two seconds from the time I'm requesting the explorer to the time the buffer-selection window comes up. This applies only when the files (buffers) are accessed over the sshfs mount (I haven't tried NFS). The number of open files does not matter - i.e. as few as 2 files in the selection window.

When I'm doing :ls the buffers are listed instantaneously.

It seems that there is some sort of file-checking every time the Explorer is requested, which requires a network round-trip.

Hi,
if I open files A/a.txt, B/b.txt, A/c.txt consecutively and then open the bufexpl, change the sort method to "Sorted by fullpath", the desired result is

A/a.txt
A/c.txt
B/b.txt

But currently it comes out to be like this

A/a.txt
B/b.txt
A/c.txt

BTW, it seems that "Sorted by name" doesn't work either.

Can be the filetype be setted to something like bufexplorer? So custom autocomands can be used.

I have found that whenever I use <leader>be to switch between buffers, the command :b# always gets me back to the buffer which I have opened first (instead of getting me back to the previous buffer).

It did work well before but I cannot say when it started to misbehave.

I am on Ubuntu 14.04, my vim version is 7.4.52 .

#33 added <nowait> to all bindings to address tpope/vim-surround#98, but that option is only available in Vim 7.3 with patch 1261 and later.

I still have systems with Ubuntu 12.04 around and it ships Vim 7.3 without patch 1261 and bufexplorer is effectively useless on such systems.

The most straightforward approach would be something along the lines of this snippet (other bindings omitted):

if v:version > 703 || v:version == 703 && has('patch1261')
    let map_nw = '<nowait> '
else
    let map_nw = ''
endif

execute 'nnoremap <script> <silent> ' map_nw '<buffer> d             :call <SID>RemoveBuffer("delete")<CR>'

This would restore the key bindings, but would also reintroduce the delay on pre-7.3 Vim and 7.3 Vim without patch1261.

Given that waiting a couple of seconds when hitting 'd' is a minor nuisance compared to complete loss of all bindings, I would say that this is worth fixing, but I'd like to get some feedback before filing the PR.

When I start vim with multiple files, bufexplorer is perfectly fast.

When I've opened lots of files, then bufexplorer gets slower and slower until it's really hard to select the correct file as bufexplorer reacts extremely slow.

jlanzarotta, first let me say how much I've benefitted from using BufExplorer over several years now. Thanks so much.

I'd love it if I could put the files in the buffer list in whatever order I wanted, completely abandoning any form of automatic sorting. This would accomplish the same thing as dragging tabs around in a graphical IDE.

Some ideas on how this could be implemented: have a separate sorting mode that's called "custom" or something like that. Then, since hitting 'd' in the buffer list deletes that buffer from the current list of open buffers, I could see having some sort of "paste" key, available in custom mode, that would put the most recently closed filename back in the list, but at the place the user hit the paste key. (I realize "p" is already taken, but I'm sure you could find something sensible.) You could maybe even make it so that deleting and pasting a buffer name while in any traditional sort mode would jump it automatically into custom mode at the moment they hit paste.

Then, when I've gotten them in the order I want at that moment, I would love to be able to cycle through the files from within the editor window itself in the order they are in the list. This would accomplish the same thing as ctrl-tabbing through buffer tabs in a graphical IDE. It would be the same thing as ":bp" or ":bn" in normal vim, but instead of going through the files in order of file number it would go by current BufExplorer list order. BufExplorer could maybe have ":BufExplorerPrevious" and ":BufExplorerNext" commands (that users could assign to some shortcut key as they saw fit). This would not need to be limited to custom sort mode, since it'd be super useful regardless of how they're sorted. By making it a command, we could jump between files in our desired order without even going into the buffer list.

Thanks for considering this. Would love to know what you think.

The hack introduced in rainbow_csv#handle_buffer_enter() of the plugin rainbow_csv on July 1st 2019 (ugly hacks) disables all syntax elements when reentering the Bufexplorer buffer by executing the BufEnter autocommand and therein

execute "set ft=" . ft_hack

because Bufexplorer has not defined a FileType autocommand.

An easy fix for me was to add the autocommand

autocmd FileType bufexplorer call s:SetupSyntax()

to the augroup BufExplorer and remove the call s:SetupSyntax() from the function s:DisplayBufferList().

Wouldn't it be awesome if bufexplorer had a possibility to expand/contract directories?

Something like

a/a/a.txt
a/a/b.txt
a/a/c.txt
a/b/a.txt
a/b/b.txt
a/b/c.txt

to

<a/a/...>
<a/b/...>

or

<a/...>

using vim folding e.g.

I'm seeing a strange issue that I've isolated to bufexplorer. (That is, it does not occur without bufexplorer loaded, and it does occur with an empty .vimrc and bufexplorer as the single plugin.)

This started happening with more recent vim versions. It does not reproduce in vim 8.0.1453 but it does occur in vim 8.1.something (can't recall which patch) as well as 8.2.65.

Edit any file with at least one line of text. I'll call mine x.txt.

Consider the command

1 | startinsert!

This should go to the first line and then change to insert mode at the very end of the line (as though the user had used the A motion).

This command works fine. However, if at the command-line I run

vim -c '1 | startinsert!' x.txt

then the cursor will be at the second-to-last position in the line rather than at the very end (as though the user typed $i rather than A).

Without bufexplorer loaded, vim -c '1 | startinsert!' x.txt starts vim with the cursor at the very end of the first line, just as though I ran 1 | startinsert! from inside vim.

I did a little bisecting and the problem is caused by this line of code:

Any way to disable the mappings for \bs and \bv via .vimrc?

Hi,

when I call BufExplorer I see an "Escaped" message in the statusbar

This doesn't happen if I use BufExplorer(Vertical|Horizontal)Split.

I have removed all my vundle bundles and reset all BufExplorer options to defaults, and this still happens. Removing all vim options doesn't help either. Any ideas?

Thanks

Lets say you have 2 tabs:

Tab 1

File1.txt
File2.txt

Tab 2

File3.txt
File4.txt

When I switch to Tab 2 and trigger bufexplorer, I expect to see:

File3.txt
File4.txt

And I get

File3.txt
File4.txt

I change to tab 1 and I get

File1.txt
File2.txt
File3.txt

I change to Tab 2 and I get

File1.txt
File3.txt
File4.txt

There's something definitely wrong there.

When using bv can the selected buffer be opened in the new split?

So if I open a new vertical split with bufexplorer and select a buffer can it fill the vertical split that was opened?

Does that make sense?

Cheers,
Otis.

I'm using BufExplorer via WinManager with all the defaults. I still see line numbers in the bufexploer.
Vim version 7.4 patched up to 629.

Thanks,
Vamsi

It would be great if we also had the option to close the explorer pressing the 'Esc' key (Or any equivalent sequence for that matter)

I use the latest version (7.4.9).When I open vim,error noticed as the title said.Could someone helps me?
My vim is VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan 2 2014 19:39:32)
and my os is 3.13.0-85-generic #129-Ubuntu SMP Thu Mar 17 20:50:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I can't find a buffer plugin that does this, so I'm hoping this is something bufexplorer could incorporate (probably behind an option). Say I open bufexplorer in a vertical split (which is what I usually do). As I move over buffers (with j and k, for example), I would like the buffer under the cursor to show up in the left pane (a "preview" if you will), and then when I press Enter, bufexplorer closes leaving me in the selected buffer (which is basically the current functionality for Enter).

Alternatively, if there's a way to define mappings inside a bufexplorer window, possibly I could make this work on my own.

My reasoning for this is that a list of file names is difficult to grok, and if you have multiple files named the same thing (or almost the same thing), it takes me longer than I'd like to locate the buffer I want.

I realize this is a complicated feature request, as you have to handle edge cases like "What if the user hits t instead of Enter?" and "What if the user closes bufexplorer without selecting a buffer? Should it revert to the buffer that was open when bufexplorer was invoked?"

Adding files to your quickfix adds each file to the buffer list as an unlisted buffer. Sometimes I have hundreds of files in my quickfix and this makes opening bufexplorer very slow (Vim 7.3 on Windows 7).

The problem is that bufexplorer is getting the full list of buffers (including unlisted ones) even if we're only showing listed buffers. Processing this enormous list is slow (on Windows). I never display unlisted files and sometimes I have 10 listed buffers and 300 unlisted, so it appears that bufexplorer takes a long time to open to display just 10 files.

I have a hack fix for this, but you can only toggle unlisted buffers when you opened bufexplorer with unlisted buffers enabled: idbrii/bufexplorer.zip@4fe272d

It doesn't collect unlisted buffers on opening bufexplorer, so it can't display them.

The hack works for me since I don't use unlisted buffers. Checking the latest code at f3bbe12, I'd assume this still occurs.