paredit based on treesitter

Since `treesitter` will be a built-in in Emacs 29, would it be feasible to base something like `paredit` / `smartparens` / `puni` on it? Something which operates on all types of source code in a generic way? Or is this out of scope? Is there already some project in that direction to contribute?

Why? I see a drawback: additional dependency for paredit. But I don't see any benefits.

[symex](https://github.com/drym-org/symex.el) has a branch that’s been working on integrating with tree-sitter.

Afaik [puni](https://github.com/AmaiKinono/puni) uses only `forward-sexp` for navigating and manipulating sexps. So if you implement a `forward-sexp-function` that uses treesit.el it should work without any changes.

Looking at `treesit-defun-type-regex` and [`treesit-beginning/end-of-defun`](https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/treesit.el#n1588) might be a good starting point.

If you use evil this might be relevant to what you want https://github.com/meain/evil-textobj-tree-sitter#Goto

If you read the original post it says > Something which operates on all types of source code in a generic way? So really they're speaking of a semantic code editor like you're able to achieve with lisp with other types of programming languages with more complex syntax

An additional dependency thats already in core?

> additional dependency for paredit. Emacs Lisp supports graceful deprecation & version-based feature dependency. It also supports simple ways to accomplish mostly the same as [seq.el](https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/seq.el?h=externals/seq#n43) demonstrates with `seq-24` and `seq-25`. treesitter is being added into Emacs as a built-in behind an optional build-time switch.

I haven't used it, but based on the description, it looks like [combobulate](https://github.com/mickeynp/combobulate) would be an example of this: >Combobulate aims to take that germ of an idea and the ideas of ParEdit and make it work as consistently and transparently across languages as possible.

It nevertheless is an additional dependency. So far I have no intention to build Emacs with tree-sitter support as I don't see how it would be useful to me at all. But if paredit becomes dependent on it, I'll have to — seemingly, for no reason.

But paredit already can do this without tree-sitter, can't it? My point is, tree-sitter does not bring anything new to editing sexps, does it? Also, Lisp development is most often image-based so it's the Lisp reader and Lisp compiler that can (and should) provide all the relevant information without requiring special support for it, like in other programming systems, for which tree-sitter was designed.

Indeed. I'm slowly revamping it for Emacs 29's tree sitter.

Sorry, your reading comprehension is really bad today. This post *isn't taking about editing sexprs*, it's talking about editing **non-sexpr languages** semantically. Essentially implementing paredit for non-paren languages using tree-sitter.

I think it should make syntax highlighting faster and or more correct as you type/edit?

Thank you for the pointer to the source. I think that that `treesit-node-next-sibling` may be better suited for this purpose.

Wait a second… /u/mickey**p** github.com/mickey**np** p/np … Are you on the verge of some monumental breakthrough? (Definitely going to have to buy your book now 😅)

I've been working on that myself, and I'm pleased to say that I'm not far of having a version ready that works with Emacs' new built-in tree-sitter library.

Oh dear... 🧐

No idea if it will work faster or more correct, but it should work with additional languages than paredit. Paredit is really useful only in lisp-like languages, and practically works best for Emacs Lisp.

No it can't. It works well with Lisp.