From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: 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:02:36 +0200 Organization: LINKOV.NET Message-ID: <87bjwjyg5f.fsf@mail.linkov.net> References: <87plox4mtp.fsf@masteringemacs.org> <86tte2a5o3.fsf@gnu.org> <877cay1lqt.fsf@masteringemacs.org> <86frpma06f.fsf@gnu.org> <86ikueiekp.fsf@mail.linkov.net> <86ed4zg1cc.fsf@mail.linkov.net> <87zflac68t.fsf@mail.linkov.net> <87jzcdlxdp.fsf@mail.linkov.net> <87o71jocgs.fsf@mail.linkov.net> <87wmfwqg7e.fsf@mail.linkov.net> <8734i5fyv1.fsf@mail.linkov.net> <875xmumpzv.fsf@mail.linkov.net> <86ikqubdsd.fsf@gnu.org> <87wmf9912l.fsf@mail.linkov.net> <867c798lco.fsf@gnu.org> <871pxhp24e.fsf@mail.linkov.net> <86cyh16nq3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16773"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) Cc: mickey@masteringemacs.org, casouri@gmail.com, theo@thornhill.no, 73404@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 06 19:07:14 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tUrVS-0004Gu-Aj for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Jan 2025 19:07:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUrVM-0007w0-4s; Mon, 06 Jan 2025 13:07:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUrVH-0007vh-M2 for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 13:07:04 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tUrVH-0000Fk-Da for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 13:07:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=C9uxwURx9CGOu4C7NUEBK9Fk/IhExJ2BPN1O6ySMOwA=; b=tGn5Ir48M/KL7U9E7dkqfRbWo3z/0WwtOzynzki5226GHwDy+XQFWQwtYPGrwvOqnMXnGYRC9/W9dFrZg2HvWBj9hMHKhh9WJq6DFgqG/8ltYuvuYPAIdFNSDv4uNIlFYWSnpi6hX3zD6wc6/hARcgnE1xCMO3c+HjxdmEVvC13GH78HDF0DcbQgeDSRgPD9ZVt06NBko8ReV4rdwKeYvfAzgi0u0BzIwklpZWii/8hIMDCeFNDci29+zkApzO1bY1kG3M49I1ER7cTXfO6xALBEXp1u2bum/2MOpyRY9PpPUTCU8WoJyj82gcs/NekulrYQj6Xg0phtCK74GfdQCA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUrVG-00027Q-6q for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 13:07:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2025 18:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73404 X-GNU-PR-Package: emacs Original-Received: via spool by 73404-submit@debbugs.gnu.org id=B73404.17361867658025 (code B ref 73404); Mon, 06 Jan 2025 18:07:02 +0000 Original-Received: (at 73404) by debbugs.gnu.org; 6 Jan 2025 18:06:05 +0000 Original-Received: from localhost ([127.0.0.1]:39991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUrUJ-00025K-V2 for submit@debbugs.gnu.org; Mon, 06 Jan 2025 13:06:04 -0500 Original-Received: from relay5-d.mail.gandi.net ([2001:4b98:dc4:8::225]:50897) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUrUG-00024i-08 for 73404@debbugs.gnu.org; Mon, 06 Jan 2025 13:06:01 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 3F78B1C0006; Mon, 6 Jan 2025 18:05:51 +0000 (UTC) In-Reply-To: <86cyh16nq3.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Jan 2025 21:54:12 +0200") X-GND-Sasl: juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298681 Archived-At: > 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. >> > 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)) >> 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. > > Sorry, I don't follow: the parentheses of the argument list are also > inside a node, and yet we do recognize them. What's the difference? The problem is that ")" is not the final child of 'cast_expression'. So C-M-f/C-M-n can't stop after ")". All these problems stem from the imperfection of ts grammars. 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. Otherwise, if vendoring grammars is not feasible, an alternative would be to define a new treesit-thing like e.g. "paren" that will match anonymous nodes like: (setq-local treesit-thing-settings `((c (paren ,(rx (or "{" "}" "[" "]" "(" ")"))) Then low-level treesit functions such as treesit-parent-until will have to check if there a preceding sibling that matches "paren" before using their real AST parent node. This means maintaining a parallel virtual tree. >> > 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"? > > 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". >> Then 'forward-list' should move over "group"? > > I'm not sure we should rename the commands, given the legacy. But > the doc string should use "group" or "parenthesized group", IMO. The doc string of 'forward-list' already uses this: (forward-list &optional ARG INTERACTIVE) Move forward across one balanced group of parentheses.