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 #235 received at 73404 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: mickey <at> masteringemacs.org, casouri <at> gmail.com, theo <at> thornhill.no,
 73404 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not
 behave as expected in tree-sitter modes
Date: Mon, 06 Jan 2025 20:45:14 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: casouri <at> gmail.com,  theo <at> thornhill.no,  mickey <at> masteringemacs.org,
>   73404 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Mon, 06 Jan 2025 20:02:36 +0200
> 
> > Another example on line 152 in dispnew.c:
> >
> >   struct redisplay_history
> >   {
> >     char trace[512 + 100];
> >   };
> >
> > Move point to the [ before 512: C-M-n will signal an error.
> >
> > Any bracket in the file will trigger either the first or the second
> > behavior.
> 
> Sorry, I didn't foresee that you would expect C-M-n and C-M-f to behave
> the same way regarding list motion.  This is fixed now by syncing
> treesit-forward-list with treesit-forward-sexp-list, so all your
> test cases work correctly now.

Thanks.

> >> > w32_get_internal_run_time (void)
> >> > {
> >> >   if (get_process_times_fn)
> >> >     {
> >> >       FILETIME create, exit, kernel, user;
> >> >       HANDLE proc = GetCurrentProcess ();
> >> >       if ((*get_process_times_fn) (proc, &create, &exit, &kernel, &user))
> >> >         {
> >> > 	  return ltime (total.QuadPart);
> >> >         }                              ^
> >> >     }
> >> >
> >> >   return Fcurrent_time ();
> >> > }
> >> >
> >> > If you put point on the semi-colon marked by "^", C-M-n signals an
> >> > error.  Can't we instead move to the next "list" after
> >> > "Fcurrent_time"?
> >> 
> >> 'C-M-n' doesn't move to the next statement in c-mode,
> >> since we need to support backward-compatibility.  The key
> >> that moves to the next statement ignoring nested lists
> >> in C modes is 'M-e'.
> >
> > Well, then maybe we could have the more useful behavior as an opt-in
> > option?
> 
> Do you also need an option to move in Lisp from 1 to 2 in:
> 
>   (compound_statement
>    (if_statement
>     (compound_statement
>      (return_statement 1)))
>    (return_statement 2))

It sounds more useful to me than signaling an error, yes.

> It would be nice if someone will find a way to modify the grammars
> after importing them to Emacs core, to be able to insert more nodes.
> This will solve a whole class of problems.

Yes, an ability to modify the grammars and recompile them into the
library would be great.

> >> So you prefer "group" over "list"?
> >
> > As a shorthand; the better term is "parenthesized group".
> 
> By definition a list is a parenthesized group.
> The term "list" is much shorter than its synonym
> "parenthesized group", so I see no reasons not to use "list".

The problem with "list" is that it is not clear what it means in
languages that are not Lisp-like.

But we can keep that in the names of commands and variables, IMO.

Previous Next

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