Buffer Delete breaks NERDTreeToggle #162

benlinton opened this Issue May 9, 2012 · 13 comments


None yet

10 participants


With the NERDTree window open and in focus, I enter the buffer delete (:bd) command. Then :NERDTreeToggle results in the following error:

Error detected while processing function <SNR>15_toggle..<SNR>15_renderView:
E121: Undefined variable: b:NERDTreeRoot
E15: Invalid expression: b:NERDTreeRoot.path.str({'format': 'UI', 'truncateTo': winwidth(0)})
E121: Undefined variable: header
E116: Invalid arguments for function setline
E121: Undefined variable: b:NERDTreeRoot
E15: Invalid expression: b:NERDTreeRoot.renderToString()

At this point the only way to fix NERDTreeToggle is to enter the :NERDTree command.

Additional Details:

Vi IMproved 7.3 (2010 Aug 15, compiled Aug 2 2011 16:49:30)
NerdTree v4.2.0
Using gVim on Windows XP

same here

@ivanalejandro0 ivanalejandro0 referenced this issue in jistr/vim-nerdtree-tabs Apr 23, 2013

Deleting NERDTree buffer causes many problems #27

diego898 commented May 3, 2013

I have the following in my ~/.vimrc

" Close all the buffers
map <leader>ca :1,1000 bd<cr>

When I execute this, nerdtreetoggle does not give me any errors, its buffer just dissapears. When I type :NERDTreeToggle, an empty split shows up where nerdtree usually apperas, and I can't get it to actually show anything. I have to restart vim to get it back.

Hello, anything new on this?
I have the same issue, only NERDTree installed and when I get the NERDTree buffer if I kill that buffer with for example :bd, then it is gone. And when NERDTree is called back, it comes as an empty buffer and everything is broken after that. Any ideas?


Assuming toggle usually fails when the tree is closed and lacking buffers, this little hack does the job:

nmap <silent> <Leader>t :call g:WorkaroundNERDTreeToggle()<CR>

function! g:WorkaroundNERDTreeToggle()
  try | :NERDTreeToggle | catch | :NERDTree | endtry
rbong commented Jun 1, 2015

The function above fails for me. The issue is that ":NERDTree" executes with errors and fails. This small fix worked for me:

nmap <silent> <Leader>t :call g:WorkaroundNERDTreeToggle()<CR>

function! g:WorkaroundNERDTreeToggle()
  try | NERDTreeToggle | catch | silent! NERDTree | endtry

Note the "silent!"
Edit: achieved the same results in a NERDTree-only vim environment.

wcamarao commented Jun 2, 2015

Thanks for the update @rbong, the one I posted before used to work, but since I updated NERDTree to current master a few days ago, it stopped working and I haven't had the chance to look into it. Thanks for sharing, I'll give it a try.

wcamarao commented Jun 3, 2015

Just verified the silent! before the NERDTree call kept the workaround valid for the current NERDTree stable.

squarism commented Jul 1, 2015

👍 This fix/thread is fantastic. Saving my sanity.

ysolis commented Oct 15, 2015

problem silenced in my workstation, Ubuntu 14.04

Rican7 commented Jul 14, 2016

I'm still having issues even with the g:WorkaroundNERDTreeToggle function.

The "errors" (status-line execution errors) are no longer being thrown, but the behavior of NERDTree opening is still off, as it causes a strange issue where my current buffer is opened in just a NERDTree size split window.

Regardless, the g:WorkaroundNERDTreeToggle function is a hacky workaround... the plugin should really be detecting the condition where the buffer no longer exists, and then handle that appropriately (fall-back to a reopening?).

Rican7 commented Jul 14, 2016

Hmm, actually this seems to be fixed by 0544ff5, which was a fix for #375.

Should this be closed @scrooloose? Maybe a patch release (5.0.1?) for the bugfix?

Rican7 commented Jul 14, 2016

Actually, I'm still getting weird behavior, even after upgrading to the newest master:



@Rican7 Rican7 added a commit to Rican7/dotfiles that referenced this issue Jul 15, 2016
@Rican7 Rican7 Updating the `RemoveHiddenBuffers()` vim function
to only remove buffers that have an empty `buftype`.

This prevents issues for plugins and windows that don't expect their
buffer to be closed in their or mishandle that state, such as:

This is all thanks to @ZyX-I and his comment on the original source for
this function:

This issue seems to have been fixed, as mentioned above. Closing....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment