How to inform neotree source about some external events

[ghostbuster91]

In my case I have a source that represents data from a language server.
That data comes asynchronously via notification to the client in two cases:

1. when opening a specific file for the first time and the language server kicks in via autocmd
2. when expanding a node that represents a compilation target, results are not available immediately but need to wait for compilation to finish

I figured out that I will use the event system as follow:

1. define new type of events
2. subscribe for these types in the setup function
3. override lsp-client handler for particular notifications
4. whenever a notification is received it fires a respective event

However, I am not sure how to update tree state without rendering it, as the rendering code is responsible for creation of NuiNodes that I use to keep the state. Rn I use the renderer.show_nodes method but it has this side-effect that it also shows my source in the neotree.

I would like only to update the state without switching the current visible source. Is this possible?

Code below:

external api entrypoint

M.tree_view_did_change = function(nodes)
    events.fire_event(M.TREE_VIEW_DID_CHANGE_EVENT, nodes)
end

setup:

M.setup = function(config, global_config)
    events.define_event(api.TREE_VIEW_DID_CHANGE_EVENT, { debounce_frequency = 0 })
    ...

manager.subscribe(SOURCE_NAME, {
        event = api.TREE_VIEW_DID_CHANGE_EVENT,
        handler = function(result)
            local state = manager.get_state(SOURCE_NAME)
            vim.notify("tree view did change handler")
            state.metals_buffer = utils.valid_metals_buffer(state)

            local refresh_node = function(node)
                local err, result = lsp.tree_view_children(state.metals_buffer, node.nodeUri)
                if err then
                    log.error(err)
                    log.error("Something went wrong while requesting tvp children. More info in logs.")
                else
                    local children = utils.fetch_recursively_expanded_nodes(result, state)
                    renderer.show_nodes(children, state, node.nodeUri)
                end
            end
            local tasks = {}
            for _, node in pairs(result.nodes) do
                -- we are only interested in nodes that have uri
                if node.nodeUri then
                    table.insert(tasks, function()
                        -- from neovim-metals:
                        -- As far as I know, the res.nodes here will never be children of eachother, so we
                        -- should be safe doing this call for the children in the same loop as the update.
                        refresh_node(node)
                    end)
                end
            end
            utils.async_void_run(function()
                if #tasks > 0 then
                    async.util.join(tasks)
                end
            end)
        end,
    })

You can find the full code here

[miversen33]

IIRC you don't have a great way of doing this with neo-tree directly (correct me if I am wrong @cseickel ).

You can in theory pull the state of your source with require("neo-tree.sources.manager").get_state and modify the attached tree variable on there but you will almost certainly be doing all of that with nui directly and therefore kinda avoiding the niceties that neo-tree provides (such as neo-tree's component system).

I very briefly dove down that rabbit hole before settling on what we talked about before, managing the state yourself. If you go that route, you don't really care when your changes happen, you just care about when to show them and that is easy enough to do with show_nodes (as you eluded to). Of course, managing your own state can be a bit of a pain

[ghostbuster91]

I was afraid that it might be the case. One of the main reasons why I try to avoid tracking the state myself is that I am not sure when I should dispose it or if I should at all. Do you have any recommendation for it? Like should my external state still be attached to the neotree state variable?

[miversen33]

Personally I am tracking Netman's state from within Netman and not from within Neo-tree. In fact, I create the tree for neo-tree each time the source is opened. This is to ensure that the tree always looks how I expect it to.

To your answer, I think that depends on the data you are showing. I built a sort of TTL Cache for Netman and it auto nils anything older than the cache's timeout each time something is accessed in it, but that doesn't affect the state too much. To the actual tree representation, I broke that into 2 pieces. I have my own node heap is a 1D key/value table where the key is the ID of the node, and the value is my own representation of what the node should contain. Its very similar to how Nui manages its tree. When a node is removed from the tree (note, removed and not hidden), I nil out the representation of the node from my stack.

The second part is the actual tree representation and that is literally just a tree where each node is just the ID of the node and a list of its child nodes (in display order). Rendering this tree is simple, I just walk the tree and convert my representation of the node into whatever Neo-tree expects a node to contain. If I cant find the node in my heap, its assumed it was deleted and it and its children are purged from the tree.

There is likely a better way to handle this but given that we don't have direct control over how and when nodes are rendered to the buffer, this is the best solution I came up with

[cseickel]

I'm working from memory here, but I'm pretty sure the rest of the sources are effectively paused and do not maintain the state of the tree at all if they are not visible.

The only exception is lsp diagnostic info. Those events will continue to come in whenever the diagnostic autocmds fire and the information will just be recorded on the state object. The tree is not directly affected by this though because LSP info is only looked up at render time and is not actually maintained within the tree nodes at all.

As an extreme example, the buffers list just calls the nvim api to list all buffers every time it is shown and every time an event fires that may change the list of buffers while it's open. If it's not open then all events are ignored. There's really no source specific state to maintain at all.

I think the filesystem source will still process file changed events from the libuv watchers (if enabled) but it won't do anything about it if the source is not visible, it will just mark the tree as stale which will cause it to refresh the next time it is opened.

As a general rule, I think it is desirable that any source that is not visible should not active in any way.

[ghostbuster91]

Thank you both for writing these answers, they are very helpful 🙇‍♂️
I think it is now clear for me how to approach implementing that another source.