In order to automatically trigger a mark holding the last cursor position when I left a buffer or window, I added these statements to my ~/.vimrc:
for more background on why I wanted to add these commands please refer to this vi.stackexchange question.
autocmd BufLeave * :normal mB
autocmd WinLeave * :normal mW
The statements are causing errors when moving out of, or closing buffers created by NERDTree or netrw. e.g. when closing a netrw buffer.
Error detected while processing function <SNR>85_NetrwBookHistHandler:
line 154:
E121: Undefined variable: g:netrw_bookmarklist
E15: Invalid expression: g:netrw_bookmarklist[iremove - 1]
line 158:
E121: Undefined variable: g:netrw_bookmarklist
E116: Invalid arguments for function remove
line 159:
E121: Undefined variable: dremove
Also NERDTree is sometimes making addiditonal copies of directories, so when I run git status, git is showing new directories.
I suspect the cause of the error is the fact that NERDTree and netrw are creating new mappings, so that the command :normal mB when executed in a NERDTree buffer is triggering something like m,l -which in NERDTree mappings means "modify" and "list" rather than set a new mark.
Does this reasoning sound right?
If so how could I detect when focus is in a NERDTree or netrw buffer, so the mappings can be turned off. Otherwise what could the cause to this problem?
:normal, does it change anything? A bang just after:normalmeans that the keys you give as an argument won't be remapped. If the keys are not remapped, maybe your autocmd will simply set marks and not callnetrworNERDTree's functions.!and so far its working nicely. I knew the!after a function name would allow you to redefine the function. But I didn't know about the!in autocmd /normalstatements. so it basically locks the command in, so that it can't be remapped? . Thanks!:help :normal. Also in the 15th and 16th chapter of Learn Vimscript the Hard Way. There are various Ex commands whose behavior is changed when you append a bang to them (like:retabor:join). When you think your problem is solved, you could post your solution as an answer.:normal!form too. So based on my testing and the assumption romainl has likely used the command without issues I guess its a workable answer that might help others.