nvim-tree.lua
nvim-tree.lua copied to clipboard
find file filtered
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
-
nvim -nu /tmp/nvt-min.lua
-
:e ~/.config/nvim/init.vim
-
: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.
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
.
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")
How about an extra setup option, something like
require("nvim-tree").setup({filters = {
find_filtered = "unhide" // "ignore", "alert", "unhide"
}})
That would work nicely, although alert seems unnecessary and intrusive.
find_filtered
could apply to a find invocation as well as update_focused_file
.
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.
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.
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
https://github.com/nvim-tree/nvim-tree.lua/discussions/1703#discussioncomment-4023779
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.
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.
@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.
It's useful and other users have expresed in interest in such functionality elsewhere.
The implementation is not too tricky, the concept and actual UX is the hard part.
This should be resolved via #1785 and #2261
Please reopen if this hasn't been resolved.
nay, the problem seems to persist
and it seems that I can't reopen the issue. perhaps some repo collaborator can verify the problem and reopen it?
Thanks for the update.