Event.TreeAttachedPost

[alex-courtis]

Event fired following on_attach call.

Context:
#1858
mrjones2014/legendary.nvim#289 (comment)

Legendary has a requirement to access / mutate user's mappings set via their on_attach.

[alex-courtis]

@mrjones2014 I would be grateful if you tested the new event:

cd /path/to/nvim-tree.lua
git pull
git checkout 1869-add-on-attach-post-event

:help nvim-tree-events

[mrjones2014]

Working on testing this today.

[mrjones2014]

So, I can probably make this work by using a FileType autocmd as a fallback, but the current API is not sufficient if the user is lazy-loading. The current events API requires that nvim-tree is loaded in order to subscribe to events. This doesn't really work if the user is lazy-loading nvim-tree, because it won't be loaded when legendary.nvim config runs, and so we won't be able to do require('nvim-tree.api').

Would it be possible to also use Neovim's built-in Autocmd mechanisms? See :h User to fire custom autocmd events. This way, I can subscribe to the event without nvim-tree necessarily being loaded.

I think the dispatch system you have could be updated to support this somewhat easily. I think you could do something like this:

-- This gives a way for `autocmd` handlers to access your custom payload
-- since the payload for our `doautocmd` call will be the nvim-tree event name
M.payload = nil

local function dispatch(event_name, payload)
  -- temporarily store the payload
  M.payload = payload
  vim.cmd(string.format('doautocmd User NvimTree_%s', event_name))
  vim.schedule_wrap(function() M.payload = nil end)
  for _, handler in pairs(get_handlers(event_name)) do
    local success, error = pcall(handler, payload)
    if not success then
      notify.error("Handler for event " .. event_name .. " errored. " .. vim.inspect(error))
    end
  end
end

This would allow hooking into nvim-tree events without forcing nvim-tree to be loaded like so:

require('legendary').autocmd({
  'User',
  function()
    local payload = vim.deepcopy(require('nvim-tree.events').payload)
    -- use the payload if needed, or do whatever is needed
  end,
  opts = { pattern = 'NvimTree_TreeAttachedPost' },
})

[mrjones2014]

This would be backwards compatible, as the existing event API still exists, and subscribing using the API doesn't subscribe any autocmds, so users can choose to use one or the other.

[mrjones2014]

Also, we would need a way to tell if Event.TreeAttachedPost has already fired or not.

[mrjones2014]

I'm also noticing that we only get the event if the user has supplied a custom on_attach function -- we would need the event to fire regardless so that we know when it's safe to grab up-to-date keymaps.

[mrjones2014]

Hm, one other thing I'm noticing, nvim-tree doesn't necessarily have a stable buffer ID. It closes and recreates the buffer. This will potentially be solvable on the legendary.nvim side with mrjones2014/legendary.nvim#256

[alex-courtis]

I'm also noticing that we only get the event if the user has supplied a custom on_attach function -- we would need the event to fire regardless so that we know when it's safe to grab up-to-date keymaps.

Ah yes, I was thinking of this as only for on_attach however it really should apply to all.

You'll then be able to examine buffer mappings directly or call config.mappings.current

Thinking about this some more: would it be useful to have TreeAttachPre and TreeAttachPost? You could use that to calculate the keymap delta i.e. the keymaps that the user has added.

[mrjones2014]

I don't personally have a use-case for TreeAttachPre, but I would need a way to know if TreeAttachPost has already happened or not -- that is, have the user-configured keymaps been applied yet or do we need to set up the event listener to wait for them?