:bd should merely close the current buffer, not close MacVim entirely.

[chrislerum]

Say I'm working with 5 files, so 5 buffers. All files' changes have been saved. I don't want the file I'm looking at to show up any more when I do :bn (buffer next), so I do a :bd (buffer delete I suppose), expecting to end up with 4 buffers, but instead MacVim closes up completely. Thanks for janus, by the way. It's been a great learning tool so far.

[tmm1]

We can probably fix this by using https://github.com/scrooloose/nerdtree/issues#issue/21 instead of b7cdd3ce6644677cae322233de8040fea3c34c29

Do you mind testing and see if it fixes your issue?

[chrislerum]

it looks like that function is intended to accomplish just the opposite of what i was after.

he wants to have vim itself close on the occasion of closing any of a set of remaining buffers (as long as none have unsaved edits of course). maybe it's a matter of work style, but it seems counterintuitive to me to have it work that way. also, i've stopped using macvim, and just use vim / tmux lately, but everything said still applies (i don't want vim closing until i tell it too, basically).

thanks tmm1, and feel free to close this issue if you wish

[curtismchale]

I've had this problem as well since using Janus. I'll have 3 buffers open and want to close one. When I :bd 1 (1 being the buffer in question) not always but sometimes MacVim closes. It doesn't Quit totally just closes the current session.

[curtismchale]

This doesn't happen if I'm closing a buffer that is not currently in focus. So I could switch to buffer 6 and then delete 7 with :bd 7 and the window will not close.

[apolzon]

If I just issue :bd (no args), to delete the currently focused buffer, my MacVim window does not close. Using snapshot #57 and latest Janus.

[thegrubbsian]

I'm also having this same issue...has anyone discovered a fix? It's kind of an annoying issue.

[tmm1]

Can someone experiencing this explain how they use buffers as part of their workflow?

I do not use buffers explicitly and have not run into this issue.

[thegrubbsian]

It's probably my naivete but how else do you use Vim without using buffers explicitly? Isn't everything essentially a buffer of some sort in the Vim?

[tmm1]

By explicitly, I meant via commands like :bclose and :bdel.

Janus attempts to mimic TextMate's tab-per-open-file model, which is how I'm used to thinking. However, this issue and pull requests for various bufexplorer plugins make me curious about what I'm missing out on.

Either way, the current behavior is obviously a bug. The commit in question attempts to close the current macvim tab/window when the only thing left on it is the nerdtree explorer. If someone can describe how they're using buffers to trigger the bug that will help me reproduce and fix it.

[kassens]

1. Open a project, say mvim ~/.vim
2. Open a file.
3. Work with that file, save it. (You can skip this step when reproducing the issue.)
4. Open another file, notice that the first file is no longer displayed.
5. :ls now shows you two open files (buffers)
6. Switch between the files with ]b or :bnext

I like to have the buffers represent the files I'm currently working on, so I can switch between them with [b and ]b without files I worked on earlier getting in my way. This is pretty much the way I use tabs in other editors.

[JohnPlummer]

Possible workaround here http://j.mp/mpQsLG. This keeps the window open when a buffer is closed though you need to map something other than :bd.

[ClayShentrup]

Yeah. I don't mean to sound extreme, but this basically makes MacVim unusable for me, despite how great everything else is. I don't want to have to go back to the command line and type "mvim ." and then re-open all my files 20 times per hour.

[kylewest]

+1 this is annoying. anyone have a workaround that doesn't require remapping :bd?

[bjensen]

+1. This makes macvim flawed.

[kalbasit]

Please try the experimental branch and re-open if the problem persists (I'm on Linux and I do not have this issue with gvim)

[chrislerum]

https://github.com/peterhost/vim-markdown-preview seems to be the active location for this; the experimental branch mentioned still linked to the defunct one (by robgleeson)

[kalbasit]

If you think the vim-markdown-preview should replace the hammer plugin then please submit a pull request against the experimental branch, Do not forget to add a rake task if it needs installation or compiling (c.f https://github.com/carlhuda/janus/blob/experimental/janus/vim/tools/tasks/hammer.rake and https://github.com/carlhuda/janus/blob/experimental/janus/vim/tools/tasks/command-t.rake to get an idea how to do that)

[chrislerum]

nope, don't even know what hammer is. just saying the experimental doesn't finish installing because it fails to find the gleeson repo.

[kalbasit]

That's weird, I haven't got this issue, would you mind opening a new issue and paste the entire output of the rake or bootstrap.sh ? Thanks

[ClayShentrup]

I tried the experimental branch but it's even more broken. E.g. command-t doesn't work.

However, I managed to "fix" this issue in the regular branch by just commenting out this line in ~/.gvimrc

"autocmd AuNERDTreeCmd WinEnter * call s:CloseIfOnlyNerdTreeLeft()

[kalbasit]

@brokenladder is the issues you mentioned are the same as #316 ? Or should I re-open this issue ?

[adrianrego]

I just added autocmd AuNERDTreeCmd WinEnter * call s:CloseIfOnlyNerdTreeLeft() to the experimental branch. Need to verify this isn't a problem.

[ClayShentrup]

It's definitely a problem. As far as I can tell, this entire function is just a bug. It causes MacVim to close when you close one of the open buffers. This is apparently a secondary bug though. :bd shouldn't be closing the whole pane just because you close a single buffer.

Here's a video. http://www.youtube.com/watch?v=IvxBoPxjeHs

[kalbasit]

@brokenladder I've removed this function in c4716fb177adb1d4d37ca201c9380374950f79c5 please let me know if you still have issues.

[ClayShentrup]

The MacVim window doesn't close, but the window (or "pane"?) containing the buffers does. Which feels like a bug.

http://www.youtube.com/watch?v=0WtK6-SULtY

[kalbasit]

Let's try narrowing it down together, does it work as expected after running this command ? (In a Terminal obviously and you should restart your MacVim)

cd ~/.vim; for submodule in `git submodule | grep -v 'core\|nerdtree' | awk '{print $2}'`; do
  echo "call janus#disable_plugin('`basename ${submodule}`')" >> ~/.vimrc.before;
done

If by any chance this works, enable back CommandT (just remove the line containing command-t from your ~/.vimrc.before) and test again

[ClayShentrup]

That does not fix the problem.

[kalbasit]

Ok I was able to reproduce, let me see if I can figure it out

[ClayShentrup]

Thanks! I have a flight to catch soon so I may not be responsive until this evening.

[kalbasit]

No problem, I'll let you know.. Bon voyage :)

[kalbasit]

I'm not sure it is a Janus issue, check this out:

rm -rf ~/.vim ~/.vimrc ~/.gvimrc
mkdir ~/.vim
git clone https://github.com/scrooloose/nerdtree.git /tmp/nerdtree
cd /tmp/nerdtree
rake

Try again and you should be experiencing the same behavior and that is just nerd tree installed, so I do not know if the behavior is intended or a bug in latest version of NerdTree

[ClayShentrup]

Seems like you're right. :(

[kalbasit]

@adrianrego would you mind checking more into this, try earlier version of Nerdtree or get in touch with @scrooloose to find out if this is actually intended behavior or just a bug

[adrianrego]

can't look into at the moment, but i know the master branch uses @wycats fork of nerdtree git://github.com/wycats/nerdtree.git

might want to start there...i'll look further into it when i get a chance.

[kalbasit]

Ok let's see if @scrooloose has some input on the issue

/cc @scrooloose

[scrooloose]

Hey guys, im not sure what you are asking me.

If you're asking me about the CloseIfOnlyNerdTreeLeft() function then, as mentioned, that's not part of nerdtree, and yeah, it seems kinda retarded (no offense to @wycats - im sure he has a huge schlong).

If you're asking me about the :bd command closing the current vim window, then that appears to be standard behaviour according to :help :bd "Any windows for this buffer are closed"

If you're asking me about something else then forgive my retardedness :-P

[kalbasit]

Hey @scrooloose thanks for responding :)

Yes we were asking about the :bd behavior, so it seems that there's nothing we can do to get what @brokenladder would like to use, @brokenladder maybe try kvbd (look at the Readme) ?

[scrooloose]

I very rarely delete buffers and if I do, i usually accept the disruption to my workflow and fire up bufexplore and clear out a whole bunch at a time.

That said, one way you could work around vim's behaviour is to switch to the new buffer (with :edit or command-t etc) and then hit :bd # to delete the previous buffer.

[kalbasit]

That's exactly what I do myself :)

Wael Nasreddine Sent from my iPhone

On Dec 13, 2011, at 0:31, Martin Grenfell [email protected] wrote:

I very rarely delete buffers and if I do, i usually accept the disruption to my workflow and fire up bufexplore and clear out a whole bunch at a time.

That said, one way you could work around vim's behaviour is to switch to the new buffer (with :edit or command-t etc) and then hit :bd # to delete the previous buffer.

---

Reply to this email directly or view it on GitHub: https://github.com/carlhuda/janus/issues/71#issuecomment-3115256

[ClayShentrup]

This video shows the problem. http://www.youtube.com/watch?v=WShMrJbGgJs

I have no idea why scrooloose rarely closes buffers. E.g. when I'm using Textmate, I don't leave 20 tabs open. I usually have the spec and the code open, and sometimes a few other files relevant to what I'm working on. I close things I'm not working on so that I spend less time searching for the particular tab I'm trying to get back to. Having spent a lot of time pairing with other devs (e.g. at Pivotal Labs), this is apparently very common behavior.

[scrooloose]

Comparing buffers to tabs is a bit bogus since buffers dont take up screen real estate when not in use and are easy to search through.

The reason I dont bother deleting buffers is because I dont often use the :b* commands directly. This is especially true when working with rails+rails.vim as there are far easier ways to navigate around - e.g. the :R* commands and :A* commands. I too often have the code/tests open side by side or just switch between them ctrl-^ or :A.

If I do end up searching through buffers then I just fire up bufexplorer which sorts by MRU - so the most relevant buffers end up at the top anyway. If the buffer is a wee way back then i just hit / and type till i find it. :b has good name completion too fyi.

If you want to know other peoples work flows you could ask on the vim-use mailing list, or #vim on freenode. Lots of pr0 guys hanging out there :)

[kalbasit]

@brokenladder I agree with @scrooloose, you need to stop thinking TextMate and start thinking Vim, what you did right there is actually opening two windows in a vertical split and then closing one with :bd, it doesn't matter what's in the window itself, try this

cd /tmp
echo 'A' > a; echo 'B' > b
mvim a

:vsp b
:bd

Same thing right ? :)

[ClayShentrup]

If I wanted to treat MacVim like Textmate, I'd use tabs. I'm clearly trying to use buffers, not tabs.

And NO, NOT the same thing. It would be the same thing if you did:

:mvim a
:e b
:bd

In which case you'd see "a". But the bug I'm complaining about here is that :bd closes THE WHOLE PANE instead of just one buffer IN the pane.

UPDATE

Okay, I see how :bd closes the whole pane (or "window", or whatever the term is) if you do :vsp. Yet this doesn't happen if you do it in the main window. That's inconsistent.

Bottom line is, I'm trying to close a buffer without closing the "pane". I remember when this issue initially came up, I found a plugin that allowed me to type :BD instead of :bd, and it would close the buffer without closing the pane. You know, the normal sensible non-surprising behavior that anyone would expect. I guess I should try to find that and just override the default :bd. But I think it would be better for that to be fixed IN JANUS.

[olalonde]

@brokenladder came here to complain about the same thing. Has this been fixed yet?

[kalbasit]

I am re-opening this and adding it to my TODO, @brokenladder please let me know if it has already been fixed, I am sorry for the huge delay, last year has been nothing but hectic (moved from France to US)

[ClayShentrup]

@eMxyzptlk No idea..I gave up on Janus long long ago.

[mollerhoj]

I worked around this issue using: map <C-x> :bn<cr>:bd #<cr>:bp<cr>

[nashio]

Here's a solution: nmap <leader>q :bp <BAR> bd #<CR> closes the current buffer and takes you to the previous one