Skip to content

find_file For New File Leaves Node In Inconsistent State #1723

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

Closed
alex-courtis opened this issue Nov 5, 2022 · 3 comments · Fixed by #1724
Closed

find_file For New File Leaves Node In Inconsistent State #1723

alex-courtis opened this issue Nov 5, 2022 · 3 comments · Fixed by #1724
Labels
bug Something isn't working

Comments

@alex-courtis
Copy link
Member

Description

find_file for a valid file that is not known in a closed directory results in the closed directory unable to be opened.

Neovim version

NVIM v0.8.0
Build type: Release
LuaJIT 2.1.0-beta3

Operating system and version

Linux 6.0.6-arch1-1

nvim-tree version

a0f3e99

Minimal config

vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvt-min/site]]
local package_root = "/tmp/nvt-min/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
  require("packer").startup {
    {
      "wbthomason/packer.nvim",
      "nvim-tree/nvim-tree.lua",
      "nvim-tree/nvim-web-devicons",
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. "/plugin/packer_compiled.lua",
      display = { non_interactive = true },
    },
  }
end
if vim.fn.isdirectory(install_path) == 0 then
  print "Installing nvim-tree and dependencies."
  vim.fn.system { "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path }
end
load_plugins()
require("packer").sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua setup()]]
vim.opt.termguicolors = true
vim.opt.cursorline = true

-- MODIFY NVIM-TREE SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
_G.setup = function()
  require("nvim-tree").setup {
    filesystem_watchers = {
      enable = false,
    },
    log = {
      enable = true,
      truncate = true,
      types = {
        all = false,
        config = false,
        copy_paste = false,
        dev = true,
        diagnostics = false,
        git = true,
        profile = false,
        watcher = true,
      },
    },
  }
end

Steps to reproduce

mkdir x
touch x/a
:NvimTreeOpen
open x
close x
!touch x/b
:lua require("nvim-tree.api").tree.find_file("x/b")

Expected behavior

Node x requires two edit to open.

Actual behavior

Open with one edit.

@alex-courtis alex-courtis added the bug Something isn't working label Nov 5, 2022
alex-courtis added a commit that referenced this issue Nov 5, 2022
alex-courtis added a commit that referenced this issue Nov 5, 2022
alex-courtis added a commit that referenced this issue Nov 5, 2022
…er unable to be opened

* fix(#1723): find_file for externally created new file results in folder unable to be opened

* fix(#1723): find_file for externally created new file results in folder unable to be opened
alex-courtis added a commit that referenced this issue Nov 6, 2022
… in folder unable to be opened"

This reverts commit be2ccd4.
@alex-courtis alex-courtis reopened this Nov 6, 2022
@alex-courtis
Copy link
Member Author

Failing for update_focused_file.enabled and renderer.group_empty. The top grouped node is expanded and its grouping discarded, resulting in two instances of the directories: one grouped, one not.

This one is tricky: grouped nodes are directly iterated during find-file, with an opportunity to refresh the actual parent node not easily arising.

@alex-courtis
Copy link
Member Author

alex-courtis commented Nov 6, 2022

Pragmatic proposal: find-file runs watch.refresh_path(absolute_parent_dir) or a reload(node, status) prior to finding.

This will fail in the case of symlinked directories, only refreshing the first one. That's an existing problem and can be seen via watchers. A full explorer reload does not suffer from this. This may be a Too Bad edge case and we can address it if needed.

A get_all_nodes_from_path function may be useful for the find-files case and could be applied to the watcher case. This needs thought.

@alex-courtis
Copy link
Member Author

Raised #1731

alex-courtis added a commit that referenced this issue Nov 26, 2022
* fix(#1731): watcher refreshes node rather than the first node matching absolute path, profile refresh

* fix(#1731): reload explorer reloads closed folders

* fix(#1731): do not fire folder created event on file create

* fix(#1731): reload profile absolute path, not link to

* fix(#1731): find-file locks/profiles on real path, reloads when watchers disabled

* Revert "fix(#1731): reload explorer reloads closed folders"

This reverts commit 5dfd8bd.

* fix(#1731): tidy watch reload

* fix(#1731): move refresh_node from watch to reload

* fix(#1731): find-file reloads all nodes for the containing directory

* fix(#1731): create-file refreshes synchronously

* fix(#1731): remove unused watch node

* fix(#1731): find-file refreshes root

* fix(#1716): create-file invokes find-file

* fix(#1731): refresh path walks down the tree to the targedt
alex-courtis added a commit that referenced this issue Dec 16, 2022
alex-courtis added a commit that referenced this issue Dec 16, 2022
alex-courtis added a commit that referenced this issue Dec 16, 2022
…ile with 15ms default (#1828)

* Revert "Revert "fix(#1815): don't schedule find_file calls, debounce update_focused_file with 15ms default (#1820)""

This reverts commit a8d26bb.

* fix(#1723): find_file for externally created new file results in folder unable to be opened

* fix(#1723): find_file for externally created new file results in folder unable to be opened
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
1 participant