If you are renaming a file via the mm hotkey and it is already opened then all
tabs and windows containing the old file will be replaced with a
new file. Current tab and windows structure is not changed anymore
If you are deleting a file via the md hotkey and it is already open, i.e.
presents in buffer lists then a buffer will be removed but a window and tab
will be kept with a ':enew' file
Previously when you delete or moved a file via
md or mm commands the NERDTree was asking you about what to do
with the remaining buffer of the just deleted or moved file. I
always press 'y' in this cases so I've decided to add a new parameter,
NERDTreeAutoDeleteBuffer which you can set to 1 in order to skip
this confirmation.
Add 2 autocmds - NERDTreeInit and NERDTreeNewRoot. These are called when
a tree is created and when the root is changed. The goal is to give the
fugitive plugin something to listen for so it can add the G* commands to
nerdtree buffers in git repo dirs.
When 'virtualedit' is set, the column where the cursor resides can no longer be
relied on for determining the number of elements in the 'line' list for
iterating. Replacing virtcol() with len() seems to work correctly and not
result in E684 errors. Fixes Issue #144
Previously if we used the gi/gs mappings on a dir node/bookmark the
cursor would end up in the new window. Now it stays in the current
window as expected
KeyMap.bind() does not gracefully handle use of '<>' notation. For
example, trying to call NERDTreeAddKeyMap() with a 'key' argument of
'<Leader>e'. There were some workarounds KeyMap.bind() to help with
this by specifically allowing you to leave off the '<>' parts for
'<C-...>', '<M-...>' and mouse mappings and it would add them back for
you before creating the mapping. This commit reverts some of that logic
and simply says that if the key starts with '<', replace it with <lt>.
These calls to NERDTreeAddKeyMap use the same callback as when these
keys are mapped with a 'scope' of "Node." This should not pose a
problem though as s:previewNodeCurrent, s:previewNodeHSplit and
s:previewNodeVSplit all just call the passed in node's open() method,
which gets passed on to an Opener object.
The core issue is that in some versions of vim resolve() will remove trailing
slashes, while in others it will not. This lead to commit
bc745b6e99 attempting to address a double slash
problem. However, that broke symlink detection on systems where resolve()
removes trailing slashes. This new function just calls vim's resolve()
function, but removes trailing slashes if they exist.
