Re: Call for volunteers: add tree-sitter support to major modes

[Theodor Thornhill <theo@thornhill.no>]

Po Lu <luangruo@yahoo.com> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>> Well, we are not talking just about fontification, but we will get all
>> sorts of ast-powered benefits.  Navigation, speed, movement, context
>> aware deletion/inserting and more. There's a whole body of ingenious
>> stuff that's been made in other editors with this framework.  They will
>> immediately be relevant for emacs as well. This is much too simplistic a
>> view, I'm afraid.
>
> Interesting.  I understand that tree-sitter is faster, but could you
> please explain what you mean by "context aware deletion/insertion"?
>

Sure!

(The following example is from the other tree-sitter implementation, but
it would be as simple, if not simpler in the new one)

Consider this code:

```
(defun csharp-delete-method-at-point ()
  "Deletes the method at point."
  (interactive)
  (when-let ((method (tree-sitter-node-at-point 'method_declaration)))
    (delete-region (tsc-node-start-position method)
                   (tsc-node-end-position method))))
```

If point is _anywhere_ inside a method, this function will delete the
whole thing.  It knows the beginning and end, and doesn't have to do
anything else than returning the relevant points.  The same could be
done with i.e. string, where if:

```
"some string here where this | denotes where point is"
```

You could create paredit-like functionality to delete _until_ the last
quote, etc.  Compare them to Vims 'cip', 'dap' etc.  These are only
trivial examples, but you could also imagine creating refactoring
functions where you extract variables and insert them in the scope of
other functions and so forth.  The huge thing here is that you have the
_actual_ parse tree.  Indentation is also now simpler, more correct.
There are all sorts of things we could evolve from here.  Font-lock is
just because that is the clearest, easiest and fastest benefit.

>> My point was that I'd consider it unfair to Alan (though he should
>> answer that himself) moving the C# variant to core, because that would
>> inevitably but even more stress on him.  _Every_ time I've had some
>> issues maintaining some problems in C# mode it has caused weeks of work
>> for Alan.
>
> Then I guess I misunderstood what you said.

No worries!

Thanks,
Theo