I'm using minibufexpl and nerdree. So when i try to open any file from nerdtree as vsplit in current buffer then it split minibufexplorer window not current editor window. It happens because nerdree split last active window but after i switch from editor window to nerdtree minibuferexpl get focus (a little time) for change colors for current active 'tab' so minibufexpl window became last active window.
Maybe vim has some options to switch 'last active window' marker from minibufexpl window to previous active window?

I don't know since what version this is happening, but while :help works as intended, with a command like :help minibufexpl.txt showing the help page for this plugin, the command :tab help minibufexpl.txt results in the following:

E433: No tags file
E426: tag not found: minibufexpl.txt@en

After these two errors, an empty tab is opened. This applies to all help pages.

Hey,

In my .vimrc I have the following lines:

" Smart way to move btw. windows 
map <C-j> <C-W>j
map <C-k> <C-W>k
map <C-h> <C-W>h
map <C-l> <C-W>l

let g:miniBufExplMapWindowNavVim = 1

Control+J or Control+K works fine to move up/down but can't go left or right.

Any ideas really appreciated.

Thanks.

Resizing windows doesn't affect the mbe window - it stays minimum height at the top of the screen, which is great. However, rotating windows with r moves it away from the edge. It should stay fixed - probably by hiding it before a window rotation and then re-showing it afterwards.

I've noticed on my machines that when open buffers starts to approach and exceed double digits, performance is significantly impaired. Opening and switching buffers goes from instantaneous to delayed, and even editing a buffer can become plagued with pauses and hiccups.

When I remove minibufexpl from my Vim plugins and replace it with BufExplorer, the issue disappears (at least up to the number of open buffers I've tried, 25 or so). Buffer opening, switching, and editing remains instantly responsive.

I've experienced this behavior in two different settings: in MacVim on a MacBook Pro, and in Gvim in Ubuntu on an AMD quad-core. Each machine flush with free memory.

I have not yet experimented with a bare Vim profile, so I can't yet rule out some sort of interfering side-effect of another plugin. I will try that next.

when I try open two differents files with same name in differents paths
vim fileName ../fileName -o
I get this error

Error detected while processing function 11_AutoUpdate..11_StartExplorer..11_DisplayBuffers..11_ShowBuffers..11_B
uildBufferList..CheckRootDirForDupes:
line 3:
E684: list index out of range: -1
E15: Invalid expression: (a:path1[a:level] == a:path2[a:level])

If I run Vim and pass at least 2 file arguments, and then press :q in the first buffer, MBE gets closed instead of the file. If I switch to another buffer, :q correctly closes that file instead of MBE. If I switch to another buffer and then back to the first one, :q again closes MBE instead of the file.

This bug seems to be present in the vim.org version too, but for some reason I've never noticed it before.

Hi!

I'm currently using the gnome-terminal to do most of my work, including all the vim stuff.
I wanted to change the colors of the MBE window (in my .vimrc):
hi MBENormal ctermfg=cyan

which has no effect, but:
:verbose hi MBENormal
MBENormal xxx cterm=bold ctermfg=6
Last set from ~/.vimrc

I also tried installing gvim (GTK) to test if it would work in a gui version. But it didn't. I also looked into the code and don't quite understand what the syntax declarations are doing. Besides i didn't find any other color specific settings, than the MBE* highlighting definitions.

So do you know, what I have to do, that highlighting works?

Thank you!
David

Hi,

I'm using minibufexpl.vim using Pathogen.

I've had the problem that using the plugin breaks filetype detection. I've been able to narrow it down to the following line:

call <SID>CycleBuffer(1)

Inside AutoUpdate(). I think a piece of code there is interfering with the autocmds that do filetype detection.

Anyway, commenting out this line seems to work for me without any ill effects. Though you'd like you know, maybe there's a structural problem in there that needs work.

Focus nerd_tree window and then click 'tab' in the minibufexpl. Buffer opens in the Nerd_tree window.
Possible fix:
line 1534:

 ...
 if bufname('%') == '-MiniBufExplorer-' || (g:miniBufExplModSelTarget == 1 && getbufvar(bufnr('%'), '&modifiable') == 0)
  wincmd w
 ...

to (for each condition line):

 ...
 if bufname('%') == '-MiniBufExplorer-' || bufname('%') == 'NERD_tree_1' || (g:miniBufExplModSelTarget == 1 && getbufvar(bufnr('%'), '&modifiable') == 0)
  wincmd w
 ...

I usually have quite a large number of tabs open. (the session I'm testing this on has 27 tabs) When I first started trying out this branch of minibufexpl, I noticed that it was incredibly slow when switching tabs; however, the original minibufexpl on the Vim site didn't have this issue. I went back through all of the downloads listed here on github, and found that the regression seems to have occurred between 6.3.7 and 6.4.0.

When I have a decent number of tabs open (I've only been testing with my current session of 27 tabs, but I can try other numbers of tabs if it'd help) I see the following behavior: Using 6.3.7, buffer switches (:bn / :bp, which I bind to <C-Tab> and <C-S-Tab> respectively) are fast; the speed is indistinguishable from stock Vim with no minibufexpl-like plugin. Using 6.4.0, it takes more than a full second to switch tabs each time I press <C-Tab> or enter :bn.

I'll clone the repository and see if I can track down a specific revision that caused this regression.

Hey there!

So.. MBE is setting "shellslash" when used on Windows. It looks like this is to make the code work that removes directory names for two files in the same directory. However.. setting shellslash on Windows is not a good idea. It causes shellquote() to use single quotes instead of double quotes, which breaks everything on Windows.

In my case, I ran into this while using Vundle. I imagine the same thing would happen with Pathogen, though I haven't tried it. When Vundle attempts to install a new Bundle with git, the command fails because the destination path is single-quoted. Commenting out the line in MBE that sets shellslash fixes the issue, though of course it causes buffers to have their full path even when they are all in the same directory.

Hello, I am using vundle plugin to manage several plugins.
I try to update minibufexpl.vim like this ...
----my .vimrc ----
"Browsing
Bundle 'fugitive.vim'
Bundle 'minibufexpl.vim'
Bundle 'The-NERD-tree'
Bundle 'Tagbar'
Bundle 'Source-Explorer-srcexpl.vim'

however I can not update it,
when I check its version through "git log".

its version is still 6.3.2

commit c05c2dcd2a8af7ff279089c300bd7f9e81bffd9f
Author: bindu wavell [email protected]
Date: Thu Nov 18 00:00:00 2004 +0000

Version 6.3.2

what happen?
Am I correct? please help me.
I would really like your new updates
from JK, seoul, korea

If I'm working in vim and I want to change my working directory to the current file I'll do :cd %:p:h but then when I open up a new file it regenerates the minibufexpl window, so then I have 2 of them.

It would be great if we could "cycle" through all buffers according to their last "use" (MRU). Just like "^Tab", but while holding "Ctrl" down and pressing Tab (again and again or holding it down) it should go to the "next-most-recent-used" buffer and so on (switching not just between the last two "mru" buffers).

I found the "miniBufExplSortBy" option but what I am looking for is another "MRU"-Option which just changes the CTab/CSTab-behavior, not the visualisation of buffers. Maybe a new option called "miniBufExplCTabSwitchBufsSortBy"?

Having trouble tracking down exactly what's causing the problem, but these are the symptoms...

I'm using the FuzzyFinder plugin as well: http://www.vim.org/scripts/script.php?script_id=1984
And I'm having a weird interaction between this and MBE.

In previous versions of MBE (from vim.org, including MBE++) FuzzyFinder would open files in the window that's currently open, and the filename would appear in the MBE window as expected, exactly as if you'd typed :e filename.

Since upgrading to minibufexpl from this git repo, I've found that opening a file with FuzzyFinder will cause a new split window to open, but it's always only a single row high and at the top of the windows (immediately below the MBE window). Even if the file is already open in a buffer, opening it with FuzzyFinder (e.g. via the "open a buffer" FufBuffer command) will make a new split window at the top, a single row high.

If I disable MBE, FuzzyFinder works fine and if I use an older version of MBE (from vim.org) FuzzyFinder also works fine (i.e. opens the file in the current window). So it seems that some interaction between FuzzyFinder and MBE 6.4.0 (also 6.4.1b1) is causing this odd behaviour.

Unfortunately it seems like @fholgado has lost interest in this project. There has been no updates for months now and no issues are adressed anymore.

This is a petty as i really like the improved version - but there are some open issues.

I found no better way than to open a ticket for this, as this may catch some attention from other developers. Is anyone willing to take over maintenance? Is there a fork which could replace this repo here?

  if (has("win32") || has("win64"))
      ""set shellslash
  endif

Breaks other plugins like Syntastic ...

Setting shellslash on Windows is not good, since it prevents shellescape (built-in function) to work as expected.

It seems that MBE uses it's own custom Status Line format to reduce the unwanted information,but I can't find anything about it in the source.
add this line in the source
'''vim
set statusline=%F
'''

I use the LustyExplorer extension and often, when i open it, i see errors like these popping up from minibufexplorer:

Error detected while processing function <SNR>22_AutoUpdate..<SNR>22_StartExplorer:
line 127:
E16: Invalid range

Original installed BuffExplored and worked well,
After install MBE,
I can't open buffer list using '\be' key,
but '\bv' works.

Is there any conflict or keymap duplicate ?

My vimrc:
https://github.com/fwolf/fwolfrc/blob/1e7a826ce71fe5509e6b84d22c273f5cb31458f8/vimrc

BuffExplorer version: 7.3.0
Vim: 7.3

Similarly to TextMate's Cmd-n for switching buffers.

What's the current behavior to select the new active buffer after deleting one ? I don't understand how it's working. I would like to select the previous opened one.

After adding

let g:miniBufExplShowBufNumbers = 0

to my vimrc file, I cann't switch between buffers by hitting enter on the tab of mbe.

Vim keeps saying:

Error detected while processing function 23_MBESelectBuffer:
Zero count: b! 0

I believe that the function GetSelectedBuffer returns a wrong value.
GetSelectedBuffer gets the count number by subtitute.

I'm not sure if this is something that should be brought up as in issue with this plugin, but I'll mention it anyway.

The easytags plugin has got a couple of lines that detects too low values of updatetime and complains loudly about it.

Currently minibufexpl does setlocal updatetime=300 which it considers too low (due to it having to update the tags that often). I'm therefore wondering if the updatetime really needs to be that low or if there's a way to make easytags not update that fast in the minibufexpl windows (in which case this probably becomes an issue for that tracker).

minibufexpl sets shellslash on windows systems.

minibufexpl.vim (line 468)

" Set shellslash for Windows/DOS Vim for dupeBufName checking to Work
  if (has("win32") || has("win64"))
      set shellslash
  endif

This seems to cause shellescape() to output shell commands surrounded by single quotes. I believe windows cannot handle paths surrounded by single quotes and thus things start breaking because shell commands stop working.

Running a command in windows cmd surrounded by single quotes yields the following:

c:\>dir 'c:\windows'
The filename, directory name, or volume label syntax is incorrect.

This would be nice feature, as generally I don't need the statusline.

I use MiniBuffExpl along side of the Fugitive plugin and I noticed that when I run :Gdiff it correctly opens two files side by side, but then diffs one of them with the MiniBuffExpl buffer. Is there a way to prevent this? I'm filing bug reports here and for fugitive to see if one of the projects can get it fixed.

Could there be a way to temporarily suppress MBE for certain calls? My workaround right now is this:

let g:miniBufExplorerMoreThanOne=3

This way MBE does not trigger when I do Gdiff.

let miniBufExplorerMoreThanOne = 0 still works for numbers greater than 0, but setting it to 0 doesn't cause minibufexpl to open even if there are no open buffers, despite what is said in the documentation.

Was still working in version 6.4.3.

I have set let g:miniBufExplMapWindowNavVim = 1 in my .vimrc but they don't work. Used on MacVim 7.3

Maybe should be set to 'minibufexpl' just the same as the plugin name.

Hey

I'm using your version of MBE, it works pretty good but once in awhile it ends up messing up and opening multiple instances of the MBE buffer (as pictured in my screenshot below):

This same thing was happening with the old vimscripts version, and it's happened to me across multiple machines, so I'm sure I'm doing something wrong on some level, but I'm not sure what or why it would open multiple buffers, got any tips?

I've upgraded to this version of minibufexpl (mainly for the syntax highlighting of the buffer) and during regular usage I have stumbled across several bugs (I think they are all related, so I am only reporting one of them).

To reproduce:

First make open VIM and make sure your buffer list is empty. Open up NERDTree explorer and open two files, which should cause MBE to "activate" upon opening the second file. At this point, instead of the focus being on the second file, it will be on the MBE window. This causes havoc if you try to proceed with your edits without realizing you ended up in the wrong window.

I believe this bug is related to these ones:

#3
#7

It has to do with the way MBE handles focus. When opening the MBE window for the first time, it should give back focus to the correct window instead of stealing focus of the window.

MBE 6.4.0
Vim 7.3.189
Ubuntu 10.04

Vim open, no files loaded, no interference.
Vim open, one or more files loaded, I get the following error on entry into the command history, and with every single keystroke while in the command history (and search histories).

Error detected while processing function 19_AutoUpdate..19_StartExplorer..19_FindCreateWindow:
line 20:
E11: Invalid in command-line window; executes, CTRL-C quits: 1 wincmd w

When opening files with the same filename using the :e command and one of them is on the same level as the CWD, it causes the error:

Error detected while processing function <SNR>17_AutoUpdate..<SNR>17_BuildBufferList..CheckRootDirForDupes:
line    3:
E684: list index out of range: -1
Press ENTER or type command to continue

Pressing ENTER just keeps on displaying the same error.

Note: It doesn't come up when opening the files via NERD_Tree plugin. Only when using :e. I'm using GVim 7.3 on Windows. Haven't tried on Mac OS X yet.

when h/l to select buffers. It's hard to see when only a cursor on screen. So I think you should add a color for current select buffer with color. really.

Hunting me since ages: MBE should always span the complete width on top. When you close NERDtree (or vimproject) and re-open it again, it will change from this layout:

BBBBBBBBB
NNNCCCCCC
NNNCCCCCC
NNNCCCCCC

to

NNNBBBBBB
NNNCCCCCC
NNNCCCCCC
NNNCCCCCC

Sorry if i'm blind and missing an obvious configuration. But i think i really tried hard. Would be great to finally see this fixed.

First, thanks for the awesome work. Love MBE. Currently running off of development branch which fixed the issue with two buffers with the same name. Running into some compatibility problems between MBE and Fugitive.

1. If I go into a git repo and run fugitive's :Gstatus, I get the change buffer and all is happy. When I run 'D' diff on a change, I get the two vertical windows with vimdiff but in the fugitive git version, syntax highlighting is not working. It changes to one color.

2. If I have a couple of other buffers open and I fire up Gstatus and hit diff, the diff windows now show up about the Gstatus window but belowe the MiniBufExplorer window and is just 1 line high. I don't think syntax highlighting is working either.

Now to be fair, this may be an issue with fugitive, but if I disable MBE, I can't find similar issues with fugitive.

I am using MacVim. When I am quitting Vim (:q) and reopening it, it always displays the last file/buffer opened. How can I suppress this behaviour? Found nothing in the Docu.

I had a problem with omni completion not working. It turned out that the minibufexpl was interfering with omni completion. Here is how I found out:

Normal keyword completion works. Omni complete does not work for any language, not just Python. omnifunc is set correctly. After I C-X C-O, nothing happens. I do ":py print globals()" and it is clear that the pythoncomplete was not loaded. I can ":call pythoncomplete#Complete(1, '')" and see it get loaded. To me this rules out it being a Vim issue. It seems something is interfering with keymapping or otherwise intercept the omni completion request. So I start to disable my plugins one by one. It turns out the culprit in my case is "minibufexpl".

I am just going to disable it for now so I can use auto completion.

Hello,

Your mbe brings neat ideas, but lower Vim's responsiveness to an unacceptable level.
I've tested with a plain Vim version 7.3.353 without any plugins / .vimrc (except pathogen).

Without mbe, if I open 20 moderately sized files (~6000 char), every buffer switch (:bn) is instantaneous.
With mbe, it takes uncomfortable fractions of second.
I've experienced delay of 2 seconds, but in conjunction with other plugins.

I've no idea how I can investigate this issue.

Regards,
Yves.

I get a noticable delay when opening multiple files from the command-line, which goes away if I comment out the duplicate name detection and replace it with the original buffer title code from the old MiniBufExpl.

Could you make this feature optional?

To reproduce:
Do a search with ack.vim: Ack! foo
Go to a file in the list list and hit the v key
The file is opened in a tiny tiny split window next to minibufexpl

The cause:
The v key in ack.vim uses the following exec "nnoremap <silent> <buffer> v <C-W><C-W><C-W>v<C-L><C-W><C-J><CR>" at https://github.com/mileszs/ack.vim/blob/master/plugin/ack.vim#L56. It goes to the top window available, splits it, and opens the selected file in that window.

I realize that key isn't mapped in minibufexpl but ack.vim is a very popular plugin. Is there a way to prevent minibufexpl from being split?

When closing a MiniBufExplorer sidebar using either \mbt or g:miniBufExplCloseOnSelect = 1, usually (but not always), only some of the rows will get redrawn.

I've tested it on gVim 7.3.50 on Gentoo Linux with MBE c80473e (6.4.1 by the ChangeLog, 6.4.0 by the version string). but I first noticed the problem with Oliver's 6.3.4 off VimScripts.

The number or rows involved varies and sometimes they're at the top while other times they're at the bottom, but they appear to always be in a single block, so my guess is that it's some kind of race condition analogous to tearing in a GUI without vsync.

I know MBE can't fix gVim bugs, but if there's some way to force a redraw sufficiently late after closing the split, that might be a workaround worth implementing.

Here are some screenshots to illustrate the problem:

• After selecting a different buffer
• After selecting a different buffer and a brief hold on the down arrow

Previously if I split the view to many windows and open some file from NERDTree, the file was opened in the last active window, but now on NERDTree opens files always in the most top-left window. Downgrading minibufexpl to 6.3.2 from http://www.vim.org/scripts/script.php?script_id=159 fixes the problem.

Looking at an editor like TextMate (and plenty of others) you can switch between files using something like cmd+1,2,3,4,etc, as well as rearrange the open "tabs" to let you switch between documents easily.

Would be useful if there was a way to access the buffers listed in MBE based on their ordering in MBE (rather than simply buffer numbers via :b# as is currently available). This would allow similar direct access to buffers (regardless of how many buffers you've opened/closed) with a common set of shortcuts.

I had a look around for alternative ways, and apparently its not possible to re-use buffers, so it seems to make sense to make this part of MBE which is displaying a tab-like set of buffer names already...?

Hi Guys,

Recently, i installed minibufexpl on MacVim(OS X 10.8.2). I found a strange issue that the minibufexpl may cause the vim code highlighting does't work.

step 1, i open source file a.cpp,the code highlighting works fine;

step 2, i open another source file b.cpp, the minibufexpl starts to display buffer explorer;

step 3, i close one source file(a.cpp or b.cpp).In this case, i closed b.cpp then the minibuf explorer was disappeared.

step 4, when i look the only left file a.cpp, i found the code highlighting was disappeared. I have to input command :syntax on to enable code highlighting.

I'm not sure it is a bug or not. So my question is how can i fix this issue?

Thanks,
Guoming

I found minibufexpl map <Leader>mq is conflict with tinykeymap.vim
Here is the error:

Error detected while processing function tinykeymap#EnterMap:
line   13:
E605: Exception not caught: tinykeymap: Map already defined: quickfixlist ,mq
Press ENTER or type command to continue
line   12:
E170: Missing :endfor

I have a few custom color highlights in my .vimrc, whenever I close a buffer I lose them, I have to restart vim to get them back, I'm using gvim version 7.2. I have the latest version from github and I've tried setting the flag to force the color syntax reload.

When mbe is visible, and a file buffer is active, :q does nothing except make the screen refresh. The buffer stays loaded, meaning the only realistic way of ending the vim session is with :qa