find file filtered

[tonyxty]

Description

With dotfiles hidden, running NvimTreeFindFile on a file under a hidden directory, e.g., ~/.config/nvim/init.vim will place the cursor on the very beginning of the tree buffer instead of focusing on the file location.

Neovim version

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

Operating system and version

Linux 5.19.7-arch1-1

nvim-tree version

fb8735e

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",
      "kyazdani42/nvim-tree.lua",
      "kyazdani42/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 { filters = { dotfiles = true } }
end

Steps to reproduce

1. nvim -nu /tmp/nvt-min.lua
2. :e ~/.config/nvim/init.vim
3. :NvimTreeFindFile

Expected behavior

• Auto un-hides dot files when finding a file under a hidden path
• Or show a message alerting the user that the file is currently hidden, and ask if they want to un-hide them.

Actual behavior

The tree is not expanded and cursor is moved to beginning of tree buffer with no alert messages. It requires the user to press 'H' to show the hidden files, and then move the focus back to init.vim window and run :NvimTreeFindFile again to get the desired behavior, which is unwieldy.

[alex-courtis]

This is working as intended: nvim-tree is filtering dotfiles as requested. The filter applies to directories as well as files.

move the focus back to init.vim window and run :NvimTreeFindFile again to get the desired behavior, which is unwieldy.

This could be made more convenient via :help nvim-tree.update_focused_file.

[alex-courtis]

Auto un-hides dot files when finding a file under a hidden path
Or show a message alerting the user that the file is currently hidden, and ask if they want to un-hide them.

The above would a change in behaviour which would be disruptive to users who expect the current behaviour.

New API would be an acceptable method forward, something like:
:lua require('nvim-tree.api').tree.find_file_filtered("/path/to/file")

[tonyxty]

How about an extra setup option, something like

require("nvim-tree").setup({filters = {
  find_filtered = "unhide"  // "ignore", "alert", "unhide"
}})

[alex-courtis]

That would work nicely, although alert seems unnecessary and intrusive.

find_filtered could apply to a find invocation as well as update_focused_file.

[gegoune]

In my opinion showing current file should take precedence over hiding/ignoring files or directories.

I might not want to see ignored files unless I open one. When I open ignored files I know what I am doing and I would like to see it in the tree as well.

Could not finding current file on open unhide structure that contains given file? It could even just stay unhidden for the remainder of the session.

[alex-courtis]

In my opinion showing current file should take precedence over hiding/ignoring files or directories.

I might not want to see ignored files unless I open one. When I open ignored files I know what I am doing and I would like to see it in the tree as well.

That is reasonable. We have been considering files under filtered directories only, however it could be made to apply to filtered files.

Could not finding current file on open unhide structure that contains given file? It could even just stay unhidden for the remainder of the session.

That will be functionally difficult: a node would need to be tagged as "no filter". When do we remove that tag? It could be on refresh, change root, close parent or on filter toggles.

[alex-courtis]

Before implementing this, a plan needs to be agreed upon:

• process for finding the file (recursive search before opening nodes may be the most practical)
• tree cleanup of filtered nodes which were excluded from the filter
• actions to take on each tree action, as well as implicit actions e.g. change root

[alex-courtis]

#1703 (reply in thread)

Maybe one-time switching off all the filters that hide the selected file (please note that I don't need to search by some part of a path) would be enough (e.g. if the path would be under dotfiles and not git-ignored, only one filter would be need to disable).

The common case is if I start nvim-tree from some dotfile under my home directory using the above mapping. While bypassing filters is not possible, I switched dotfiles to false.

This one-shot may be a pragmatic solution. The lifetime could be very short, perhaps only whilst the focus stays in the tree.

[przepompownia]

This one-shot may be a pragmatic solution. The lifetime could be very short, perhaps only whilst the focus stays in the tree.

@alex-courtis To be clear: It's a minor issue for me, not worth of encouraging you to spending hours for finding tricky implementation or reinventing some fundamental part. Rather, I hope that I overlooked something in docs (like with full_name in another issue) or that such implementation can be simple and your (or other's) knowledge can allow find some reasonable balance more quickly.

Offtop: switching from good fern.vim used by me almost two years, I started to use and customize nvim-tree three weeks ago (finding some with watcher and written in Lua and having some experience with chadtree). Most of this customization turned out relatively easy, some of them required looking into the source code, not only the API layer. Only a few required someone to ask. Thank you for providing a good alternative.