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
Thank you for submitting this issue! I ran into this myself yesterday while trying to edit a Git commit message in Vim.
The culplit is the following line:
autocmd MiniBufExplorer CursorHold * call DEBUG('-=> CursroHold AutoCmd', 10) |call AutoUpdate(-1,bufname("%"))
It updates MBE after any keypress, and it's opening a new buffer after the :q command is issued. Let me see what I can do to prevent this from happening. I'll keep you posted on the details. Let me know if you have any suggestions!
moopet, take a look at the release I just pushed. I actually killed 2 birds with one stone here! I wrote an intermediary function so that Vim checks if it needs to update before it updates, and it ends up solving the issue you reported. Take a look here:
Please give it a try and let me know if it's fixed on your end!
In my experience with minibufexplorer (and previously with minibufexplorer++ from Oliver Uvman - http://www.vim.org/scripts/script.php?script_id=3239), ":q" has never been a clean way of quitting vim if MBE is visible. This continues to be a problem in MBE 6.4.1b1 from the repository.
The first time I type it (with the cursor in a document, while MBE is visible), MBE will vanish but the document won't. The second time I type it, the document will close as normal with :q (possibly showing me another buffer at this point if there are more open, otherwise quitting vim).
If I type :wq instead, MBE will become hidden, but typing :wq again will write the file but not close the buffer nor quit vim (although I've only noticed this happening since switching over to this git version of MBE).
The behaviour I'd expect is that :q would close the file buffer (rather than just hiding MBE), and (perhaps?) if MBE is the last buffer open, quit from vim. Though I may be misunderstanding the way vim buffers are meant to work (I've only switched recently to buffers from MacVim tabs).
I haven't found a specific combination of settings that fixes this behaviour, but for the record my settings are:
let g:miniBufExplMapWindowNavArrows = 1
let g:miniBufExplSplitBelow = 0
let g:miniBufExplMapCTabSwitchBufs = 1
let g:miniBufExplorerMoreThanOne = 1
I've done some research into this issue. After the latest release, Vim is now at least exhibiting normal behavior.
The :q command closes the current window. MBE uses it's own window, so therefore when you close the last actual buffer, the MBE window still remains.
I will write a function to detect when MBE is the last buffer open and have it close vim automatically.
I'll keep you updated on the progress.
I have written the preliminary function and have gotten it to work in some cases, so far it works well when doing a :bd but not when doing :q. One more night's worth of work and I should have it ironed out. I'll probably be able to get to it this coming weekend.
the :q command works like drfrogsplat described it. I am using development branch. Is there any chance to get that fixed?
I apologize for the delay! My MacBook is at the Apple Store for repairs this weekend, so I have not been able to work on the plugin. I have made some progress and I should have this issue fixed shortly after I get my computer back. Thanks for your patience!
I'm having the same problem too. I can't get :q to do anything useful.
Me too. Please fix.
Same issue here, my MBE config:
let g:miniBufExplMapWindowNavVim = 1
let g:miniBufExplModSelTarget = 1
let g:miniBufExplorerMoreThanOne = 2
Hope you're able to fix it.
While trotting around the web I came across this:
And discovered it works fine for MBE too:
au BufEnter * call MyLastWindow()
" if the window is quickfix go on
" if this window is last on screen quit without warning
if winnr('$') < 2
as MBE's buftype is "nofile". I don't know enough about vimscript to fix it right now, but I can report that this in my vimrc solves the problem for me :)
This looks like a brilliant solution! Has it interfered with anything else so far in Vim? It will be very simple to implement in the code. I will go ahead and implement it in the development branch so that people can test it out and see if they report any problems. Awesome find :)
Just as a note, I've added this to the latest dev build here:
Can everyone please take a look and make sure it works OK and does not conflict with anything else?
Thanks so much!
I've had the same problem in Tagbar, you can check my solution (which also handles the case of more than one open tab) here:
The idea is originally from taglist.
Can you walk me through what is happening in the code? You may have updated something and the link you sent is no longer pointing to the right line. I did see a CleanUp() function, is that what you're referring to?
Thanks for helping out!
No, I was referring to the QuitIfOnlyWindow() function a bit further down:
Any updates on this? I'd be interested in a fix.
I'd also be interested in a fix. Is the fix in a branch somewhere?
I am in still suffering this issue? any update for it or MBE setting?
my setting are
let g:miniBufExplorerMoreThanOne=1 "solve to conflict with nerdtree
let g:miniBufExplMapWindowNavVim =1 "0, "ctrl+hjkl window move"
let g:miniBufExplUseSingleClick =1 "1, "mouse single click
let g:miniBufExplModSelTarget =1 "1, "with other windows like Taglist
please help me
this is work around solution.
please refer below link (the first code)
I guess this will help you.
:q works fine here when editing a single file, but when multiple buffers are opened pressing :q will always just close MBE and switch to the first buffer.
I have continued the developement of MBE for a while, a bunch of PRs have been merged into the develop branch of my fork.
I believe that weynhamz/vim-plugin-minibufexpl@cea185b, weynhamz/vim-plugin-minibufexpl@7ebc049 and weynhamz/vim-plugin-minibufexpl@b0d4c4a should fix this issue.
Please give it a try and let me know if it works.
Hey, I am closing this issue, because I believe it has been fixed in the develop branch of my fork and will soon be avaliable in @fholgado's repo in the coming relase 6.5. If the problem still remains, feel free to reopen it.