This small change reverts to the previous method of breaking shell
output into lines. The reason for this is to avoid the printing of
trailing carriage return characters on Windows.
The (l) menu command breaks on Windows systems when 'shellslash' is
set. This is due to the fact that the menu item uses a hard coded
shell command, thus relying on the use of the default Windows shell
without the 'shellslash' setting.
The pattern used for the fix is localized to the problem function.
However, this technique could easily be abstracted into its own
function to execute Windows shell commands with the default shell
throughout the NERDTree codebase.
This check did not use the proper abstract method to check for a
path separator. It now does.
This fixes a problem with the 'u' macro that I noticed while working
on the fix for using the NERDTree with 'shellslash'.
This method used the brittle "Path._escChars()" method to do its
work. This created problems when 'shellslash' was in use on Windows
because excessive escape characters (i.e., backslashes!) are
interpreted by Vim as additional path separators.
The above problem made it impossible to edit files with weird names
using the NERDTree on Windows with 'shellslash' set. For example,
'+' should be escaped with ":edit", but '(' should not. So, when
escaping '(', Vim on Windows correctly sees the start of a new
directory in the path.
This was reported in five issues which may be read for further
details and commentary.
Fixes#398, fixes#474, fixes#653, fixes#674, and fixes#733.
Several issues (namely issue #733) report problems with using the NERDTree
on Windows when 'shellslash' is set. This commit doesn't solve all of these
problems, but it improves the NERDTree's recognition of this setting.
Especially note the improvements to the commentary on "Path.str()".
This method does too much. However, it is used heavily, and changing
its interface would be a major undertaking at this point.
This commit is the first in a series of commits that will rework
some of the methods responsible for escaping pathnames. Some of
these methods simply don't use the features that Vim has properly.
The custom "Path._escChars()" method is far too rigid for our
purposes, and better options have been available for some time.
See ":h fnameescape()" for an especially helpful function in this
effort.
The highlighting rules "NERDTreeClosable" and "NERDTreeOpenable" did
not recognize files beginning with a "~" character. This caused bad
highlighting on systems that use "~" and "+" for the dir arrow
symbols by default. Making these rules more specific solves this
problem.
The "~" characters in quickhelp section titles also would get
confused with a custom mapping for "~". Adjusting the
"NERDTreeHelpTitle" solved this problem.
I also changed the quickhelp title in a minor way to reflect the
proper spelling of "NERDTree".
The previous change to this function was simple. I figured that it
would be a good time to improve the style of this function with some
minor edits. The function is now cleaner and more readable.
Two key changes were made:
1. A screenshot was added for visual appeal.
2. The massive (and noisy) feature list was removed. This
information is adequately covered in the docs.
Fixes#573.
When bookmarks are opened normally (i.e., when a bookmark is made
the root of the current NERDTree), any open children of that
bookmark will remain open.
This is often inconvenient, especially for users who want bookmarks
to appear "fresh" when opened.
The "TreeDirNode.getDirChildren()" method is never called and can be
safely removed.
Further, note that this method has a bug. It calls the "filter()"
builtin function, which modifies "self.children" in-place. This is
obviously not a desirable side effect of calling this function.
If the functionality is genuinely required later, "filter()" should
be called on a copy of "self.children" to achieve the desired
result.
As reported in issue #67, the function driving the `p` mapping was
not updated to work as expected when the cursor is positioned on a
cascade. This problem is addressed here.
Fixes#67.
The support function for this method was unnecessary, so I took the
time to remove it. Since "TreeDirNode.openRecursively()" now calls
the "open()" method, it can take advantage of the improvements made
to that function in recent commits. Specifically, this method will
reflect the bugfix provided in pull request #720.
A proper instance method was substituted for the more brittle
equality test in the "TreeDirNode.open()" method.
Note that the order of the tests was reversed to account for the
fact that the "isRoot()" method can only be called after the first
test has passed.
This method required adjustment to take cascades into consideration.
Since the arrow in the NERDTree window reflects the status of the
tail directory of the associated cascade, an arrow indicating open
status can be present when a higher directory in the cascade was
closed.
This commit will automatically close child nodes within the same
cascade of a closed directory node so that the arrow accurately
reflects what is rendered.
Issues #547 and #526 reported a problem with the "open()" method in
the "TreeDirNode" class.
Specifically, opening a cascade in the NERDTree will perform the
opening operation on the tail of the cascade. This is a problem when
other operations (such as the "u" mapping) close intermediate
cascaded directories, which causes opening the tail to have no
effect (other than toggling the arrow).
Here, the "open()" method was modified to open all directories in a
cascade whenever the tail is opened. This is the only reasonable fix
for this type of problem.
Fixes#547 and fixes#526.
Calling the function "globpath()" is complex when one is trying to
support multiple versions of Vim because this particular function
developed rapidly (as did "glob()") during the life of Vim 7.0.
This commit makes the version check for calling "globpath()" much
clearer. It also allows for rendering dead links in the NERDTree by
changing the "globpath()" call for versions of Vim that include
patch 7.4.654. This can be done later when the effects are known and
the feature is officially requested.
Fixes#718.
The commentary in "tree_dir_node.vim" needed to be cleaned up a
little. Spaces after leading quotes are a good idea, to avoid the
"clustered" appearance that comments can sometimes have.
Use the following substitution command...
:s/^"\ze\S/" /
to make this change to longer scripts.
Pull request #710 also brought to my attention some glaring code
duplication in the TreeDirNode class. This commit renames and
expands the glob method defined in PR #710 into a more general
purpose helper method.
The new method also ensures that 'wildignore' rules are applied
consistently. Issue #569 noted that the application of the
'wildignore' setting in populating a node's children was
unpredictable. When a node was rendered, "_initChildren()" would
load the children with its own call to "globpath()". Refreshing the
same node would then invoke "globpath()" again, but with different
arguments.
The result was that a node's children were initialized using the
'g:NERDTreeRespectWildIgnore' setting, but refreshing ignored this
setting. So, if it the setting was 0, "test.class" might render when
the parent was initialized, and then be removed on refresh (if
'wildignore' contained '*.class').
This commit solves this problem by ensuring that the NERDTree
setting mentioned above is only checked and applied to a node's
children in one place by cleaning up the duplication.
Fixes#569.
Pull request #710 correctly noted that TreeDirNode directories must
be passed to "globpath()" as relative paths (i.e., to the working
directory) if 'wildignore' rules for relative paths are to be
obeyed.
The solution was to use "fnamemodify()" to get a relative path to
the TreeDirNode object's directory, if possible. However, this
method does not modify our TreeDirNode path if it IS the current
working directory. Thus, immediate children of the node are seen as
absolute paths in glob results when our PWD is pointing to their
parent. This is not consistent behavior.
This commit defines the result of this function as ',' when this
special case arises to fix this problem.
See ":h 'path'" for an explanation of how this works.
Older Vim versions seem to require that calls to sort() specify a
dictionary when the compare function argument is a dictionary
function. This seems to be required even when the dictionary is not
used. Since this change does not seem to affect behavior in later
Vim editions, I see no harm in including it.
Issues #597, #642, and #650 all report problems with the NERDTree
handler function for middle mouse clicks. In all cases, the problems
arose from the use of a function that didn't exist and from the use
of a bad argument in the call to the "g:NERDTreeAddKeyMap" function.
The fix for the first problem is obvious, but the solution to the
second bug merits explanation.
Previously, middle click events in the NERDTree window were
triggered with the "<MiddleRelease>" Vim key code. Since
"<MiddleMouse>" is always triggered before "<MiddleRelease>", The
error in #642 was bound to occur (because of the default behavior
for middle mouse clicks). Thus, the problem was easily solved by
using "<MiddleMouse>" instead of "<MiddleRelease>" in the mapping.
As an enhancement, I added the trigger of a "<LeftMouse>" event as
the first command in the handler function. This will cause the
middle click to reposition the cursor below the pointer before
continuing with its normal behavior. The benefits of this are clear.
This mapping has no defined behavior for bookmarks. Unless an issue
is raised to address this, it will be left just so for now.
Fixes#597, fixes#642, and fixes#650.
In Windows, fnamemodify with ':.' will strip the drive letter from a
path that isn't under CWD. This update ensures such a path has the drive
letter.
references #709
