Re: Plug treesit.el into other emacs constructs

[Theodor Thornhill <theo@thornhill.no>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuan Fu <casouri@gmail.com>
>> Date: Wed, 14 Dec 2022 16:05:10 -0800
>> Cc: Theodor Thornhill <theo@thornhill.no>,
>>  emacs-devel <emacs-devel@gnu.org>,
>>  eliz@gnu.org
>> 
>> > I see, so maybe sexp means the general, flexible AST entity. And thinking of it, my idea is just forward-list :-) And we definitely should include forward-list into the list of navigation commands we want to support, among the ones that are already brought up.
>> 
>> Ok, upon closer inspection, forward-list isn’t exactly what I’m thinking about, it moves over lists, but I’m thinking about moving over elements of a list.
>> 
>> If you think about it, there are two kinds of constructs in an AST/grammar: those are repeatable, and those are not. Statements are repeatable, you can stack multiple ones together and it still makes sense. Identifiers are not repeatable, put two together doesn’t make sense (in most languages).
>> 
>> And these repeatable constructs appears at every level of the AST, from top-level stuff like function definition, to statements, to small stuff like arguments in an argument list. That makes them very good unit of navigation.
>> 
>> Navigation commands, IMO, needs to be extremely easy to predict and requires no thinking. That’s the reason why avy never grow on me: yes you can move to anywhere you want, but it takes so much cognitive load to use. Much better to type a few C-n, C-M-f, etc to get their, because I don’t need to think about it.
>
> FWIW, for me, "sexp" in its C/C++ interpretation always means
> "expression".  So in
>
>    foobar (a, b + c, 2 * d - f / 10 + pow (g, x), y);
>
> C-M-f should move to the next comma on the top level (i.e. the comma
> inside the 'pow' call doesn't count), and C-M-f inside the 'pow' call
> should move by commas on that level.
>
> More generally, C-M-f should move to the next expression
> _on_the_same_level_, without entering inner levels.  Exactly like we
> do in Lisp.

Agreed