Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A newly written file cannot be found with NERDTreeFind #779

Closed
lifecrisis opened this issue Dec 10, 2017 · 14 comments · Fixed by #1005
Closed

A newly written file cannot be found with NERDTreeFind #779

lifecrisis opened this issue Dec 10, 2017 · 14 comments · Fixed by #1005
Labels

Comments

@lifecrisis
Copy link
Contributor

To replicate:

  1. Open Vim in home directory.
  2. Open the NERDTree.
  3. In the empty buffer to the right, run command :w test.txt.
  4. Next, run :NERDTreeFind.
  5. View the error...

Looks like a refresh is needed before :NERDTreeFind is run.

@lifecrisis lifecrisis added the bug label Dec 10, 2017
@lifecrisis
Copy link
Contributor Author

Making a note here that several issues may be possible duplicates of this issue... no time to look into it right now.

@juanibiapina
Copy link
Contributor

I have the problem in my fork, but you can't just force a refresh because it might be very slow for some directory trees.

@lifecrisis
Copy link
Contributor Author

lifecrisis commented Dec 21, 2017

There are a few things that need to be dealt with here:

  • findAndRevealPath() needs to be updated to remove some duplication and use better style
  • the documentation for :NERDTreeFind has to be modified to reflect the new behavior (directories as well as files can now be found and an argument can be passed)
  • an efficient method needs to be developed to show the new file (i.e., something faster than a full refresh)

I'm doing some work on this right now...

lifecrisis pushed a commit to lifecrisis/nerdtree that referenced this issue Dec 21, 2017
The ":NERDTreeFind" command calls the "reveal()" method on the
NERDTree root node.  The "reveal()" method would, in turn, call the
node's "open()" method.  Since the "open()" method would only
initialize the child nodes of the root (i.e., read them from disk)
when the list of child nodes was empty, new paths would not be
included in the list.

This commit will result in the refreshing of the child node list
whenever "reveal()" is called on a directory node (unless it is the
first time the node is being opened... the most efficient option).

The result is that ":NERDTreeFind" will discover newly created paths
that exist on disk but are not cached in the NERDTree.

A stray debugging message is also removed.

Fixes issue preservim#779.
@lifecrisis
Copy link
Contributor Author

For some reason this didn't get closed...

Closing now.

lifecrisis added a commit that referenced this issue Jan 5, 2018
Revert the bugfix from pull request #785 and reopen issue #779.
We keep the good style changes from PR #785 intact.
@lifecrisis lifecrisis reopened this Jan 5, 2018
@lifecrisis
Copy link
Contributor Author

I had to reopen this issue because the fix that was added in #785 caused problems reported in #793. A new fix will have to be devised and added later.

@PhilRunninger
Copy link
Member

This seems to be working now too.

@juanibiapina
Copy link
Contributor

When was the actual fix introduced?

@PhilRunninger
Copy link
Member

From what I can piece together, #785, merged on 12/22/17 ,fixed this issue, but introduced issue #793, which was reported on 1/2/18. PR #794 fixed that bug when it was merged on 1/5/18.

@juanibiapina
Copy link
Contributor

My understanding is that #794 removed the whole fix for this.

@PhilRunninger
Copy link
Member

I don't know what happened in the last two days. Maybe nothing. Maybe I was testing something else. I was sure it was working, but now, when I follow the steps in the original issue, I see the following error:

Error detected while processing function <SNR>59_findAndRevealPath:
line   42:
E716: Key not present in Dictionary: putCursorHere

@juanibiapina, @lifecrisis, Is that what you're seeing?

@lifecrisis
Copy link
Contributor Author

@PhilRunninger, the fix was removed. I don't remember the reason, but I remember thinking it was a good idea at the time... so this is still broken, unfortunately.

@juanibiapina
Copy link
Contributor

This is how I fixed it on my fork: https://github.com/juanibiapina/vim-lighttree/blob/edd2da237f615441012679f47c371494966dafa1/autoload/lighttree.vim#L46

I just refresh the whole tree if the node cannot be found. For me that's a good trade off between speed and correctness, because the refresh only happens if the node cannot be found.

The code there has diverged considerably, but a similar fix should be possible here.

rhiroyuki added a commit to rhiroyuki/dotfiles that referenced this issue Jun 12, 2019
With a new created file that is not yet on the NERDTree node.
When invoking NerdTreeFind on that file it will raise an error because
of that file not being located in node nerdtree. This issue was raised
in NERDTree repo but still not fixed. This is a temporary fix since it
just mitigates the error by refreshing the node.

preservim/nerdtree#779
@rstacruz
Copy link

This still happens to me when, for example, using :NERDTreeFind with vim-startify.

A workaround is to use :silent! NERDTreeFind rather than just :NERDTreeFind.

@PhilRunninger
Copy link
Member

@rstacruz Your comment is the exact issue reported in #1059, which has just been resolved with the merging of pull request #1081.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants