Bug #1778: "Error detected while processing BufLeave Auto commands"

Comments

1. Greg Hurrell 2011-02-11T07:24:53Z

   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)

2. anonymous 2011-02-11T10:42:17Z

   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.

3. anonymous 2011-02-19T22:59:51Z

   having the same issue under macvim.

4. anonymous 2011-03-09T09:53:47Z

   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.

   Here is my vimrc (Very short vimrc): https://gist.github.com/861968

5. anonymous 2011-04-01T11:20:27Z

   Having a similar issue when I try to open a file:

   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.

6. anonymous 2011-04-03T10:36:37Z

   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)

7. Greg Hurrell 2011-04-03T19:44:29Z

   Just tried again to repro this and can't see it myself.

   So if anyone who can repro it would like to submit a patch to work around the issue I'd be happy to look it, but can't do anything about it myself.

8. utkarsh Created 2011-04-11T23:09:36Z, edited 2011-04-12T00:46:14Z

   Hi Wincent,

   I'm having the same problem on Ubuntu 10 and 11. I can consistently reproduce the error using the following steps:

   1. cd into an existing project with a few files (I used rails new foo && cd foo).
   2. Start command line vim in foo vim ..
   3. Search for a file (I typed gf that brought up Gemfile as the first result) and press return.

   Screenshot of the error - http://dl.dropbox.com/u/2164813/tmp/command-t-bug-1778.png

   I'm using the following hack as a temporary solution for now - http://dl.dropbox.com/u/2164813/tmp/command-t-bug-1778.diff.txt

   I'm using NERDTree, BufExplorer, and a few autocomplete plugins with vim right now. Snapshot of the current settings is available at https://github.com/utkarshkukreti/dotfiles/tree/13a74b6ee55ec58aa5e9ffa122583849d3eaa79b

   If you need any more help trying to debug this, feel free to contact me by mail. I'd be happy to help.

9. Greg Hurrell 2011-04-12T05:56:12Z

   Hmmm, your so-called "hack" doesn't look that hackish to me. I'll give it a try here and see if there are any adverse effects.

10. Greg Hurrell 2011-04-12T06:30:02Z

    Ok, I've been able to reproduce using command line Vim and your instructions, but your patch doesn't resolve the issue for me.

    At least now I can repro, though, so I think I'll be able to fix it.

11. Greg Hurrell 2011-04-12T06:39:16Z

    Status changed:

    • From: new
    • To: open

12. utkarsh 2011-04-12T08:43:44Z

    That's strange. I sent the patch to two of my friends, and it worked for them (Both on Ubuntu 10.10).

13. Steve Losh 2011-05-25T17:15:51Z

    I'm seeing the same problem with MacVim 7.3 on OS X.

    I tried utkarsh's patch and it did make the errors go away, but the GoToFile window is still open at the bottom of the screen until I either close it manually or go to another file.

14. anonymous 2011-06-06T02:15:59Z

    This was fixed for me by updating my copy of macvim. I wasn't good about checking version of my old one, but updating to macvim snapshot 57 seems to have done the trick.

15. anonymous 2011-06-28T02:38:11Z

    Utkarsh's patch "fixes" the issue for me.

16. anonymous 2011-07-08T19:05:13Z

    The problem only appears on first use for me. The BufLeave autocmd occurs before the selected file is opened, so at the time, the match window is the only open buffer.

17. dmkash 2011-08-19T18:26:33Z

    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.

18. anonymous 2011-08-22T09:03:46Z

    I have the exact same issue as dmkash.

19. anonymous 2011-08-30T17:21:48Z

    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!

20. Greg Hurrell 2011-08-31T07:29:24Z

    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.

21. anonymous 2011-09-04T01:45:05Z

    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.

22. anonymous 2011-09-04T01:50:58Z

    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.

23. anonymous 2011-09-12T20:01:36Z

    Just to clarify: mvim . with macvim 61 is still broken

24. anonymous 2011-09-13T09:56:36Z

    I too can go around this by using mvim instead of mvim . Finally.

25. anonymous 2011-11-19T19:06:01Z

    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.

26. anonymous 2012-01-15T19:03:36Z

    Still broken.

    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.

    Can you guys reproduce it this way?

27. Marius Gedminas 2012-01-15T19:37:19Z

    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.

28. Marius Gedminas 2012-01-15T19:38:53Z

    Incidentally, 'vim .' followed by \t followed by <Ctrl-W> q closes command-t without any errors.

29. Greg Hurrell 2012-04-06T21:13:56Z

    Closed bug #1949 as a duplicate of this one.

30. Greg Hurrell 2012-04-06T21:14:39Z

    Cross-referencing this forum topic.

31. Greg Hurrell 2012-04-08T02:30:38Z

    Attempted fix for this here.

    Should arrive on the the GitHub mirror and the Gitorious mirror within about half an hour.

32. anonymous 2012-04-18T21:52:53Z

    This still happens for me. When I start vim with a directory (e.g. to drop into NERDTree) I see this error every time I try to use Command-T in that session.

33. Greg Hurrell 2014-03-22T20:41:13Z

    Closing due to lack of activity.

34. Greg Hurrell 2014-03-22T20:41:16Z

    Status changed:

    • From: open
    • To: closed

Add a comment

Comments are now closed for this issue.