tree-edit VS tree-sitter-langs

I am using this idea to build an ai-first, reactive IDE (after talking to marcelle, who's brilliant). DM me at @eating_entropy on Twitter or email me at [email protected] if you are interested.

Also it seems tree-edit implements something similar using reazon, a relational language library in elisp.

https://github.com/ethan-leba/tree-edit

tree-edit

I use it daily, so I suppose it's useable enough; there's some weird edge cases and annoying behaviors I never bothered to solve, and the README isn't complete. Development has pretty much stalled due to some loftier projects of mine but if there's interest I could be convinced to clean it up a bit more :)

you can add this one to the list ;) https://github.com/ethan-leba/tree-edit

I just had a quick look at tree-sitter-langs to double check its TypeScript support. And seems to have a full set of highlight queries for it.

I use script/compile swift from 'tree-sitter-langs' to build the grammar on both M1 and x86 machines. But I was looking at that code yesterday and I actually can't figure out why it works to produce an arm64 dylib for me. There's no place where the target arch is being set. It's very odd.

However, there are no queries available for it to highlight csharp: https://github.com/emacs-tree-sitter/tree-sitter-langs/tree/388dcbbc237b2b1360e5b148e67b158eecede805/queries

I've forked tree-sitter-langs with https://github.com/kiennq/tree-sitter-langs that can be used to convert from the current emacs-tree-sitter syntax to the built-in treesit's syntax. Based on https://github.com/emacs-tree-sitter/tree-sitter-langs/pull/99.

Those grammars are collected in the tree-sitter-langs repo, or you can build them yourself. I assume they're not bundled with Emacs yet, even on the feature branch. I don't know how the Emacs tree-sitter branch expects them to be registered and associated with a language mode, though.

The "essentially" qualifier is just because of the tree-sitter issue I was mentioning earlier which is just that this 3rd party package does not ship binaries built for FreeBSD. Everything else has worked exactly the same as on Linux.

Now I am speculating, but I think it would take less work to go through tree-sitter route. Seems that emacs tree-sitter repo already supports Elixir. And then we would need to write Elixir specific queries for combobulate, which supports incremental selection à la expand-region.