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 19:40:39 +0200 Organization: LINKOV.NET Message-ID: <87plkzyh60.fsf@mail.linkov.net> References: <87plox4mtp.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> <87a5c5v5z8.fsf@thornhill.no> <877c79qhcs.fsf@mail.linkov.net> <87sepxt4yl.fsf@thornhill.no> <87o70k9y2e.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34194"; 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, Eli Zaretskii , Theodor Thornhill , casouri@gmail.com, 73404@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 06 18:51:21 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 1tUrG5-0008lL-DQ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Jan 2025 18:51:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUrFn-0005Tz-VM; Mon, 06 Jan 2025 12:51:03 -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 1tUrFm-0005Tg-6d for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 12:51:02 -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 1tUrFl-0006WM-Uj for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 12:51:01 -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=v1h6NC788TppZgkDHGD3SwwKKYU5goiv7Vpnb1n73o0=; b=DOytC36VGUArT2SxRRw+UjoxjMPWiD7QEfJL7XUmA2+sw53OUxYXi3DIeiWM8MccB67Yk+wy5l7AeHRj3Ky35ykx/Y9J8KxvuATArB2KZmLofV68vwTnNyuWqdSwSYLQ2YfCdp8kT8TKtUwjciwu2tmFnz5qHCcGkJc6Mn01DqS/Ug9adXvwRISoSy59HwGW8fV8YJBZLXQBDNjjnryms5dyLng/lVRNc9DwceWfFhPZG7VIXCe3WD/A4LS24NglA2iTM+c/2FI6xC7sUsaw78o6zvVSRidgnumg9uSql3T/yxlinjv2BV1KE+xmb99AkqhBx7zhLjV0EYyUqf5rLQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUrFl-0001JY-Ov for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 12:51:01 -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 17:51:01 +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.17361858265009 (code B ref 73404); Mon, 06 Jan 2025 17:51:01 +0000 Original-Received: (at 73404) by debbugs.gnu.org; 6 Jan 2025 17:50:26 +0000 Original-Received: from localhost ([127.0.0.1]:39954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUrFC-0001Ii-0w for submit@debbugs.gnu.org; Mon, 06 Jan 2025 12:50:26 -0500 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:43979) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUrF9-0001I5-Q5 for 73404@debbugs.gnu.org; Mon, 06 Jan 2025 12:50:24 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 5961EFF80A; Mon, 6 Jan 2025 17:50:13 +0000 (UTC) In-Reply-To: (Stefan Monnier's message of "Mon, 06 Jan 2025 09:14:58 -0500") 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:298678 Archived-At: >>> However, deciding on what makes sense is hard, which is why I'm >>> suggesting we try to define a "spec". It needn't really be much more >>> than reference suggestions for mode implementors at first, then maybe >>> some intersection of features crystallize across all modes. >> >> I don't think it's possible to find a spec better than Stefan already >> defined as an AST node delimited by an opening and a closing "keyword": >> (...), [...], if...fi, begin...end, ... > > IIUC, Theodor was talking more generally than just about "list" operations. > I think "list" operations are among the clearest case (BTW, I wonder if > someone has already tried to implement that functionality for Haskell or > Python, Recently I looked at python-ts-mode, but then discovered that it completely misses any use of treesit-thing-settings unlike many other ts-modes. Also there is no treesit-thing-settings yet in the new haskell-ts-mode. > where the opening and a closing "keywords" are basically newlines). The main problem with empty opening and closing keywords is that nodes from different levels all end up at the same position, and currently treesit prefers a higher-level node. This means that the sequence of `C-M-f C-M-b` is not idempotent anymore: `C-M-b` might jump to the start of a higher-level node. >> Or when looking at the commands with the 'forward-' prefix: >> >> forward-sexp (C-M-f) >> forward-list (C-M-n) > > OK, we already talked about these two. We could probably start drafting > a kind of guideline. Also in treesit.el, forward-sexp and forward-list could share the same implementation. >> forward-symbol > > This one doesn't look too hard either. > >> forward-sentence (M-e) > > This one is trickier. You just provided a reasonably good start with > "In languages with statements a sentence corresponds to a statement", > but there are some non-trivial questions about language without > statements, about use within comments, about how to handle nesting > (e.g. statements within statements) and more generally the use of `M-e` > from outside of statements. I've checked that `M-e` in text-mode currently doesn't support sentences in nested lists. For example, `M-e` jumps inside the list in: Top sentence. (First inner sentence. Second inner sentence.) >> forward-paragraph (M-}) > > This one is also tied to filling, so it's important for it to behave > well w.r.t to comments to allow filling actual text paragraphs > within comments. This provides an opportunity to move treesit-specific code from `prog-fill-reindent-defun` to treesit.el. > As for its behavior outside of comments ... > >> forward-page (C-x ]) >> forward-word (M-f) > > I think these should be oblivious to the syntax (i.e. line `forward-line` > and `forward-char`). > > Your list missed the "defun" unit of navigation. Because there is no `forward-defun` ;-) But strange that "defun" still is defined by `treesit-defun-type-regexp` instead of a "defun" thing in `treesit-thing-settings`. > One other potentially useful unit of navigation that depends on the > syntax would be "list element", which would do something like skip to > the next/previous separator delimiting elements of the nearest enclosing > paired delimiters. For {...;...;...} blocks, this would behave like > `forward-sentence`, except that when used from within the args of > a function call like a `foo (..., ..., ...)`, it would jump > between arguments instead of skipping all the way to the next statement. Indeed, there is a need to have an additional command to move between more ATS nodes, besides the list nodes navigated by 'C-M-n'. But the problem is to find free keys for more commands.