Haven't seen this one personally. So for some reason it can't unload the buffer.
I wonder if you have any settings in your .vimrc which might be responsible for this; can you post the contents of your .vimrc?
Also, does this happen all the time? Or is there only a limited set of circumstances under which it occurs? (ie. when there are no buffers open, when there are multiple buffers etc)
Hey I'm the one who's currently dealing with that error. Wincent I believe you have a Mac, so if you would be inclined to download and compile a local version of Vim 7.3 (the one that I'm using) so that it might help you better understand some of the problems (ie - it might have to do with the configure options).
My vimrc hasn't been a problem before and Command-T worked fine on my Ubuntu installation.
Anyways, you can download the code (as I'm sure you'd rather read it before running it) for a script to install Vim 7.3 on your Mac here, let me know if you have any issues.
PS - Using a regular terminal with iTerm 2.
having the same issue under macvim.
I am now seeing this same issue as well, but under vim on Ubuntu, compiled with Ruby 1.9.2.
I notice it, though, under one condition: If now buffer is actually open (IE I just started vim), it will throw the same error.
Error Dected while processing function CommandTAcceptSelection cannot unload last buffer
This only happens however if I try using this command-t when I'm not already in a file. For instance if I do a vim . in my current directory and I'm in my NERDTree by default, this is when I get that error.
Also having this problem, would love to use Command-T but it's probably not that useful while this persists.
Again, it only happens for me when there are no buffers open (e.g. in a directory listing after first opening MacVim)
I can confirm that the error is still present in MacVim snapshot 61 running on Mac OS X 10.7. It is only when I open a project directory in MacVim and I don't have an actual file open. Once I have some buffers going, Command-T works as expected.
I have the exact same issue as dmkash.
I'm also having this issue, just like dmkash described. Any ETA on this one? It's the only bad part of CommandT, the rest is golden!
I haven't had much time to work on Command-T of late so I don't really have a reliable ETA.
There was Utkarsh's patch (see above), but that doesn't fix the issue, at least on my machine, so I can't really merge that in.
FYI, it appears as though 7.3-61 fixes this on Lion (via homebrew). Was having the problem with *-60 and upgrade to be pleasantly and unexpectedly surprised.
Amended about fix in 7.3-61 - still have problem when I start with "$ mvim ." but not if I start without the directory, so "$ mvim" works fine. I don't know if this was the case in the previous version of mvim.
Just to clarify: mvim . with macvim 61 is still broken
I too can go around this by using mvim instead of mvim . Finally.
I discovered that netrw was causing this on my setup. You can turn it off by adding let g:loaded_netrwPlugin = 1 to your vimrc. While I was trying to debug I also found out that for some reason netrw doesn't count as a buffer. When you open macvim with only netrw, then VIM::Buffer.count registers as 0.
I think the reason this faults is when you use NERDTree. For example: mvim . and when NERDTree is the active buffer do <leader>t and select a file -- boom! the error.
A boring /me too: on Ubuntu with latest command-t from git (without NERDTree; with just netrw) I get the unload buffer problem when I do 'vim .' followed by \t followed by ctrl-c. The "fix" makes the error message on ctrl-c disappear, but it also leaves the command-t window open.