emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plug treesit.el into other emacs constructs


From: Perry Smith
Subject: Re: Plug treesit.el into other emacs constructs
Date: Tue, 13 Dec 2022 14:06:56 -0600


> On Dec 13, 2022, at 13:53, Yuan Fu <casouri@gmail.com> wrote:
> 
>> 
>>> I mean, what construct is each one expected to jump over?
>> 
>> In my book "sexp" movement should jump over subtrees of the AST.
> 
> It’s pretty hard to judge which subtree to move over at a given point in an 
> AST. For example, when point is at | in the following text:
> 
> (|X.y(z), alpha)
> 
> Should point move over X, or X.y, or X.y(z)? All three subtrees has their 
> beg=(point). A human can tell (and might disagree on) which unit to move 
> across, but a program couldn’t tell. Without language specific knowledge, it 
> can’t really decide.
> 
> Just a thought, but maybe we can let major modes define what’s an “abstract 
> list”, and sexp-forward would move across the immediate children of abstract 
> lists. Eg, abstract lists in C would contain block, argument list, statement, 
> etc. And in the example above forward-sexp would move across X.y(z) because 
> it’s an immediate children of the enclosing abstract list, the argument list.

How about this:

Most languages have a well known precedence for operators and usually these are 
documented with words like “additive operators”, “multiplicative operators”, 
etc.

The difference between X, X.y, and X.y(z) I would say are likely known to the 
user.  In other words, they are probably thinking “I want to move past the 
function call” or more reasonably, “I want to move to the next parameter”.

With some thought, a keymap could be devised so that <prefix>-p would move to 
the next parameter, <prefix>-m would move past the multiplicative subexpression.

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]