Is this tool suited for editor integration?

[haikyuu]

Many editors integrate with tree-sitter at a deep level (neovim, emacs, helix, nova ...). And This tool is very interesting and useful.

It would make much sense to create editor plugins for it.

I'm using neovim as my daily editor. And I'd love to get gum diffs in my workflow.

I'm not very familiar with java, which gumtree is written in. So I wonder how possible it'd be to create a plugin around it:

• Is it required to have Java installed locally to run it?
• Can Gumtree be provided as a binary that could easily be distributed across platforms?
• I skimmed through the perf. section in the original paper. And 40-80ms seems like fast enough for the use case. Are there any performance considerations to take into account for this use case?

[jrfaller]

Hi, and thanks for the kind words about GumTree.

Of course it could be integrated into an IDE. However the current implementation requires Java and the integration with tree-sitter is not ideal since it goes through a Python bridge. The integration with tree-sitter makes it also tricky to have an easily installable package that works across platforms, since tree-sitter is native while the Java part is not. Furthermore the tree-sitter bridge has to be installed using a Python stack and the rest using a Java stack.

W.r.t. to the perf I think it's really OK for IDE integration. The perf you look at are the one of the original algorithm, but since then I have released an much more optimized algorithm that is much faster (and simpler to implement).

Ideally if I had the resource, I think that I would roll out a Python implementation of the optimized algorithm and it would make the distribution of GumTree simpler.

For a very good neovim integration, I think another good way to go would be to reimplement GumTree's algorithm in C, it would be very fast, could be integrated seamlessly with the tree-sitter stack already available, and would be distributed like the rest of the code.

One possible pain point however would be the display of the diff, since I am not familiar with the possibilities offered by the GUI library behind the scene of neovim, and displaying a structural diff with move is not trivial.

I hope this answer your questions!

Cheers.

[haikyuu]

Thanks for the reply @jrfaller

This is super useful. Then i should "just"™️ implement the algorithm in a system language (C, lua, rust ...)

In that case, I should rewrite the tree-sitter-parser as well as the core of this library right?

Sounds doable. From where can I get a spec for the algorithm?

P.S: I guess I could reuse the tests in this repo. I'll just rewrite them in whatever language I end up picking.

[jrfaller]

Yes! I think C or Rust are the best candidates. I think that the library to import tree sitter ast is very easy to rewrite. The other part to port is the diff algorithm. The best documentation is the Java code. Should you try to accomplish this, I could provide you the list of files that need to be ported. Cheers.