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

View this message in rfc822 format

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: bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes
Date: Sun, 05 Jan 2025 15:02:31 +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: Sun, 05 Jan 2025 09:32:58 +0200
> 
> >> >> BTW, my initial intention was to add the thing 'list'.
> >> >> But then I discovered that (treesit-thing-next (point) 'list)
> >> >> uses the function 'list' instead of the thing 'list'.
> >> >> 
> >> >> However, the current 'sexp-list' as a two-word composite is too ugly.
> >> >> Now I found a better replacement: 'group'.  This word is already used
> >> >> in lisp.el such as in the docstring of 'forward-list':
> >> >
> >> > I don’t have an opinion on this.  Groups sounds a bit abstract, but so
> >> > does sexp-list.
> >> 
> >> Indeed, the right name is 'list'.  So let's use it.
> >
> > Please don't change the terminology yet.
> 
> This doesn't change the terminology.  The ugly name was added a week ago.
> We need to fix it to the right name.  The right name is 'list' to
> conform to the function name 'forward-list'.
> 
> > I'd like to try these commands with some tree-sitter modes and see
> > what names we could use for them.
> 
> The command is 'forward-list'.  With 'list' it will do in ts-modes
> the same that 'forward-list' already does in non-ts modes.

Thanks.

I tried this now in c-ts-mode, and it seems to behave strangely in
some cases.

First, AFAICT it supports "lists" enclosed in "(..)", "{..}" and
"<..>", but not "[..]".  Is that expected?  Why don't we support
"[..]"?

Next, it many times signals an error "No next group", which is less
useful than it could be.  For example:

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"?

Also, it sometimes "misses" what looks like a "list".  For example:

s_pfn_Open_Process_Token = (OpenProcessToken_Proc)
			    get_proc_addr (hm_advapi32, "OpenProcessToken");

If you put point at the beginning of the line, C-M-n moves to the end
of the 2nd parenthesized group, not to the end of the first group.

As for terminology: the Emacs user manual calls these "groupings
delimited by parentheses (or whatever else serves as delimiters in the
language you are working with)", or in short "parenthetical group".
Why cannot we keep this terminology?  It sounds like it describes its
subject as accurate as we can come up with.

Previous Next

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