GNU bug report logs -
#73404
30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes
Previous Next
Reported by: Mickey Petersen <mickey <at> masteringemacs.org>
Date: Sat, 21 Sep 2024 05:13:01 UTC
Severity: normal
Merged with 74366
Found in version 30.0.50
Fixed in version 31.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
Message #202 received at 73404 <at> debbugs.gnu.org (full text, mbox):
>> 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
> "[..]"?
This looks like a bug. It would be nice if you posted an example.
> 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"?
'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'.
> 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.
Welcome to the twisty maze of tree-sitter grammars. C-M-n is unable
to move to the first group because it's inside the node in the AST:
(cast_expression "("
type: (type_descriptor type: (type_identifier))
")"
value:
(call_expression function: (identifier)
arguments:
(argument_list "(" (identifier) ,
(string_literal " (string_content) ")
")")))
Both the first and the 2nd parenthesized groups are inside the
"cast_expression" node.
> 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.
So you prefer "group" over "list"? Then 'forward-list'
should move over "group"?
This bug report was last modified 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.