What do you think about that neovim feature?

[daniilrozanov]

Hi! Since you are the plugin author, who might be interested in the
features that I propose, could you send some feedback on the issue
below (I mean in that issue's page)?

Feature: Treesitter features for non existent (anonymous) grammar/static AST

neovim/neovim#35907

This question should be closed.

[CKolkey]

I'll have a think about this. I'm not 100% sure this would be a huge help, but an AST would get rid of some of the more "hack" things I've needed to do. But I'll give you a sense of how I think about this for neogit, and you can tell me your thoughts.

First, check out the "renderer" module. It takes a tree of components (something defined in the code base - text, row, column primitives) and turns that into a tree of nodes, highlight ranges, fold locations, and some fast lookup tables connecting the ui "objects" to data. Think being able to find "what is the git object id of the thing I am selecting" or "what is the starting line and ending line of the diff my cursor is in". The latter I think pretty cleanly maps to your proposal.

For large buffers (log view with many entries) just applying highlights takes a considerable proportion of the render time. Having a way to hand highlighting off to the "syntax" instead of relying on the api might be a big win in that case.

I don't think I could hand off folding, since we create "fake" folds for hunks, lazy loading them the first time a user "unfolds" the region. After rendering its a normal fold. But we would need to track that state.

One aspect that may be helped by a proper AST would be just updating parts of a buffer on rerender, instead of throwing the whole thing out each refresh.

[daniilrozanov]

I don't think I could hand off folding, since we create "fake" folds for hunks, lazy loading them the first time a user "unfolds" the region. After rendering its a normal fold. But we would need to track that state.

As you already mentioned, if we could deliver API for partial buffer update, there wouldn't be a problem. Fake folds -> getting hunks -> updating ast (need neovim support) -> real foldable region. Is that correct? So, partial deleting, adding and updating buffer needed.

What worries me more is that we need to somehow distinguish syntactically identical nodes based on the data they mean. It's not so clear to me how to do

connecting the ui "objects" to data

in the context of this proposal. Definetly there must be some map between ast and data. As far as I know, the treesitter nodes do not contain any meta information that could be a reference to the data they mean. It's just a clear syntax

PS. By the way, I wonder how magit does this in emacs.

[CKolkey]

Yea, there would either need to be some lua table that mapped a node to some data, or even better, the treesitter node could contain the metadata. That would be really slick.

It seems like magit leverages a function thing-at-point, but I only took a cursory glance. Since neovim and emacs have such different buffer/rendering primitives I never really looked into it.