-
-
Notifications
You must be signed in to change notification settings - Fork 625
Event.TreeAttachedPost #1869
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
Comments
@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
|
Working on testing this today. |
So, I can probably make this work by using a Would it be possible to also use Neovim's built-in Autocmd mechanisms? See I think the -- 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 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' },
}) |
This would be backwards compatible, as the existing event API still exists, and subscribing using the API doesn't subscribe any |
Also, we would need a way to tell if |
I'm also noticing that we only get the event if the user has supplied a custom |
Hm, one other thing I'm noticing, |
Ah yes, I was thinking of this as only for 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 |
I don't personally have a use-case for |
I'm sorry I don't think I'm understanding... User's |
Yes. The buffer will be deleted when the tree's window is closed. We use a simple I'm not sure that's something you should need to work around: how difficult is it? |
Basically, in a lazy-loaded environment, I won't be able to tell if
I have a PR up in |
I see. I did not consider the ordering case. Options:
|
I'll need to consider this one carefully; we went with a custom eventing system for simplicity and ease of end user use. Additional events are always possible and cheap to implement. |
The main reason I think using the built-in autocmd system would be a lot better is for lazy-loading environments. Normally I would do something like So basically if the end-user is using
I think something like this is needed either way so that I can detect if |
I see. I was thinking in terms of Packer. Does lazy call nvim-tree's setup? nvim-tree won't do anything until setup is called, however the user can still subscribe to events at that time. |
In This is the root of what I'm trying to do -- lazily hook into |
I understand. I am learning a lot today. It sounds like we need three things:
It seems that you would need to create your autocommands before the lazy is started. |
Yeah, I concur. I think that should be sufficient. |
Opened #1893 |
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
.The text was updated successfully, but these errors were encountered: