Errors on filter input area

[przepompownia]

Description

On filter area E and <CR> mappings reveal lua errors.

Neovim version

v0.10.0-dev-1412+g1094d0c0d

Operating system and version

Debian Sid

Windows variant

nvim-tree version

78a9ca5

Clean room replication

local configDir = vim.fn.expand('<sfile>:p:h')

vim.env['XDG_CONFIG_HOME'] = configDir
vim.env['XDG_DATA_HOME'] = configDir .. '/.xdg/data'
vim.env['XDG_STATE_HOME'] = configDir .. '/.xdg/state'
vim.env['XDG_CACHE_HOME'] = configDir .. '/.xdg/cache'
local stdPathConfig = vim.fn.stdpath('config')

vim.opt.runtimepath:prepend(stdPathConfig)
vim.opt.packpath:prepend(stdPathConfig)
local pluginsPath = vim.fn.fnamemodify('plugins/', ':p')

for name, url in pairs{
  ['nvim-tree'] = 'https://github.com/nvim-tree/nvim-tree.lua',
} do
  local installPath = pluginsPath .. name
  if vim.fn.isdirectory(installPath) == 0 then
    vim.fn.system { 'git', 'clone', '--depth=1', url, installPath }
  end
  vim.opt.runtimepath:append(installPath)
end

require('nvim-tree').setup {}

local function test()
  local treeapi = require('nvim-tree.api')
  treeapi.tree.open(pluginsPath .. '/nvim-tree')
  treeapi.live_filter.start()
  vim.schedule(function ()
    -- vim.api.nvim_feedkeys(vim.keycode('<CR>'), 'i', false) -- lua/nvim-tree/live-filter.lua:86: Invalid 'buffer': Expected Lua number
    vim.api.nvim_feedkeys('wat', 'i', false)
  end)
end

test()

Steps to reproduce

1. nvim --clean -u nvt-min.lua
2. Press <CR> to finish insert mode
3. Press <CR> again. I get

E5108: Error executing lua: ...ee-expand-filter/plugins/nvim-tree/lua/nvim-tree/api.lua:164: attempt to index local 'node' (a nil value)                                                                                                       
stack traceback:
        ...ee-expand-filter/plugins/nvim-tree/lua/nvim-tree/api.lua:164: in function 'f'
        ...ee-expand-filter/plugins/nvim-tree/lua/nvim-tree/api.lua:48: in function <...ee-expand-filter/plugins/nvim-tree/lua/nvim-tree/api.lua:46>

4. Press E. I get

E5108: Error executing lua: ...tree/lua/nvim-tree/actions/tree-modifiers/expand-all.lua:61: attempt to index local 'base_node' (a nil value)                                                                                           
stack traceback:
        ...tree/lua/nvim-tree/actions/tree-modifiers/expand-all.lua:61: in function 'f'
        ...ee-expand-filter/plugins/nvim-tree/lua/nvim-tree/api.lua:48: in function <...ee-expand-filter/plugins/nvim-tree/lua/nvim-tree/api.lua:46>

5. Optionally, please look what happens after uncommenting the line with vim.keycode() and starting nvim again. It's a side effect of creating repro, not from real usage.

Error executing vim.schedule lua callback: ...d-filter/plugins/nvim-tree/lua/nvim-tree/live-filter.lua:86: attempt to concatenate upvalue 'overlay_bufnr' (a nil value)
stack traceback:
        ...d-filter/plugins/nvim-tree/lua/nvim-tree/live-filter.lua:86: in function <...d-filter/plugins/nvim-tree/lua/nvim-tree/live-filter.lua:85>

Expected behavior

• no errors described above
• E could act the same way as on the root node.

Actual behavior

Describerd in steps

[Akmadan23]

Got it, I'm working on a solution. Thanks for reporting it.

[przepompownia]

@Akmadan23 thanks for looking here. Currently for me with e0ab14e

• <CR> stopped triggering error
• E still triggers error as before.

[Akmadan23]

E still triggers error as before.

Are you sure? I tested it and I'm not getting any error...

[przepompownia]

Sorry, I overlooked that it still is not merged (and on the other side wonder why this issue is still not closed by PR) 😉

After the actual switch both errors does not occur. The proposition of mapping E to expansion the root dir remains open.

[Akmadan23]

The proposition of mapping E to expansion the root dir remains open.

Yeah, we could do that but it's incompatible with the fix I applied, to accomplish that we should re-think how the call to that specific function must be handled. In my opinion it's not worth it since one can just move the cursor up one position to expand the root dir.

[przepompownia]

Yeah, we could do that but it's incompatible with the fix I applied, to accomplish that we should re-think how the call to that specific function must be handled. In my opinion it's not worth it since one can just move the cursor up one position to expand the root dir.

Let merge e0ab14e especially if an implementation would be too complicated for little benefit.

[Akmadan23]

Let merge e0ab14e especially if an implementation would be too complicated for little benefit.

Sure, we just have to wait for a project member, I don't have permissions to merge PRs.