GNU bug report logs - #73404
30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes

Previous Next

Full log

Message #70 received at 73404 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Theodor Thornhill <theo <at> thornhill.no>, Eli Zaretskii <eliz <at> gnu.org>,
 Mickey Petersen <mickey <at> masteringemacs.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 73404 <at> debbugs.gnu.org
Subject: Re: bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not
 behave as expected in tree-sitter modes
Date: Thu, 12 Dec 2024 09:17:44 +0200

>>> Ah, this matches my idea of defining sexp in other languages as “repeatable
>>> construct/list-like construct”.  We went with “every syntactic construct” at
>>> the time, which I didn’t object to, but I’m definitely happier with the
>>> repeatable construct approach. Including Stefan and Theo since they were
>>> part of the original sexp navigation discussion.
>> 
>> FWIW, we have both `forward-list` and `forward-list` and the new
>> behavior you suggest sounds closer to the historical behavior of
>> `forward-list` than `forward-sexp`.
>
> Actually, what’s the difference between forward-list and forward-sexp?
> I always thought they are the same at least for Lisp.

forward-sexp moves over a balanced parenthetical group like
forward-list does.  Plus forward-sexp also moves over an atom
such as a symbol, a number.

The problem is that treesit adds too much structural information
to such simple things as a symbol and a number.  For example, in js
a simple keyword "export" gets the "(export_statement export" subtree,
Another keyword "const" gets "(lexical_declaration kind: const", etc.

Therefore for such symbols forward-sexp needs to bypass the structure
and use simpler syntactic information to move over them like on a flat list.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.