From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#68899: Treesitter's forward-sexp-function Date: Sun, 4 Feb 2024 12:40:33 +0000 Message-ID: References: <981BC2F8-9B7F-40AC-9C1A-C995A71F5C97@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39047"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68899@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 04 13:41:46 2024 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 1rWbog-000A1y-7z for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Feb 2024 13:41:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWbo5-0006PZ-NV; Sun, 04 Feb 2024 07:41:10 -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 1rWbns-0006N7-D2 for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2024 07:40:57 -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 1rWbnp-00078k-B1 for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2024 07:40:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rWbo1-0006rQ-7p for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2024 07:41:05 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Feb 2024 12:41:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68899 X-GNU-PR-Package: emacs Original-Received: via spool by 68899-submit@debbugs.gnu.org id=B68899.170705045926246 (code B ref 68899); Sun, 04 Feb 2024 12:41:05 +0000 Original-Received: (at 68899) by debbugs.gnu.org; 4 Feb 2024 12:40:59 +0000 Original-Received: from localhost ([127.0.0.1]:48290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWbnt-0006p8-LV for submit@debbugs.gnu.org; Sun, 04 Feb 2024 07:40:58 -0500 Original-Received: from mail-io1-xd2d.google.com ([2607:f8b0:4864:20::d2d]:46128) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWbnr-0006oi-Jz for 68899@debbugs.gnu.org; Sun, 04 Feb 2024 07:40:56 -0500 Original-Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-7bf2c826a5aso156053539f.0 for <68899@debbugs.gnu.org>; Sun, 04 Feb 2024 04:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707050437; x=1707655237; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lMKdl9AfqNp3N29pz90ic3IxW6lTlmegKu+9EZL3ros=; b=TBcvyiZHaCAxUInLmtweI1rpc6PE8GWm8hVQj3TDCKclpjyU9blp2WHjKbEZKWDLsM b//GWMd9YiSgVm9iefyPgNI8T5k0splf+3ZJpZQ3cCNFeHmnlB1PDkrHVQ4xO1qM9apR CRmgn5/WX7ivAARX+THoOGJhqKjCiOMAOcts8ZHFikzfAJN+DhEWiNXUu/+Ie9SPIwt4 ZNjTakHoGIvFzchKRfqi6h+LUNXkRR+Jhhg7Jp9h+27P0eGt2/MYekTQW7K+L2BqGbJ2 2Zl71mntYLSHtf/au9uI14zla4W9V6nbkTSmoFeTu9mCw2HdIk+fnwRHH84MtCgj2Q5l 2VGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707050437; x=1707655237; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lMKdl9AfqNp3N29pz90ic3IxW6lTlmegKu+9EZL3ros=; b=tnh7GBxw4OlLRUBLId7q6cTihO2frUVBukxtFoVmvnOgjeTmwYTKn36rdjKm16HG21 Nu8FVPuXzw8vuD5txoXGRyOquUCUqQ0wYZ4nAmqW03hDo1TnYBvZ4xkIWupM7YEkwt+q f2VUvh/kVlXZDJTl3ktPGncFFMeo7CwY/aUSBd8YPN52+CMK+SAEoIDH355M4s7YBtej anWm8Kdm0sezEfPTMbDPsrugGWbEkYQGICzAMuVBlNvulNBYiFafVdghSxjirh8MTOMP UKXh4BeZlSHZUjB7JF/VbIXIwRxqDHHpH33V1Ft9k+BuG2rHKvSjB8KzfVkz9lpvaLYa 7BiQ== X-Gm-Message-State: AOJu0YzXsq5RgAJbmug0LoWHGsJuRclO39YP5+eb/V6hnxTBGJBgWlfB VaDT0hs2Q5gTwu68w3vUBj6mCSvKowXprM+M776L5+T7YpPAeyleUyi6Ed0wa4ofaymjXd8goKv DiXycGQEg0kaQMRv+XB44I/WaWpQ= X-Google-Smtp-Source: AGHT+IFfnlbq6w/Am+BdsYkGxMIR7cSs8f1DvHJGp3F4VpZhRM3R3G9F+htTEHHWPlt/izscC9CnB/0bDEJuaJDBARQ= X-Received: by 2002:a6b:ec04:0:b0:7c3:dd3b:5e85 with SMTP id c4-20020a6bec04000000b007c3dd3b5e85mr698894ioh.1.1707050437592; Sun, 04 Feb 2024 04:40:37 -0800 (PST) In-Reply-To: <981BC2F8-9B7F-40AC-9C1A-C995A71F5C97@gmail.com> 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:279405 Archived-At: On Sun, Feb 4, 2024 at 5:35=E2=80=AFAM Yuan Fu wrote: > Thanks for looking into this, Joao. IME a very useful characteristic of f= orward-sexp is that it stays in the same =E2=80=9Clevel=E2=80=9D and doesn= =E2=80=99t go up automatically when there=E2=80=99s no siblings (when there= =E2=80=99s a closing delimiter). Eg, in an Elisp buffer, forward-sexp stops= at the closing parenthesis, in C, it should stop at the closing bracket. I agree. There are other useful characteristics, but this is one of them. It allows be to mark regions of text up to points that I'm not even seeing. > Also you don=E2=80=99t want to check for prev when moving forward, and vi= ce > versa, ie, we don=E2=80=99t want to check (null next) and (null prev) tog= ether. I get it. I used those existing results as a proxy to know if we're in the middle of a leaf. I _think_ it's sound (maybe I'm wrong). > So, how do you like this patch: It works fine, but as far as I can tell does exactly the same as mine, and looks to be slightly more difficult to read and uses a further treesit query to check if this is a leaf node. But it's absolutley fine really. One way my patch can be described in plain english is "if we're not at an inter-thing boundary, we navigate to such boundary" And then the meaning of checking prev _and_ next becomes obvious and it isn't necessary to perform the additional check that we're in a leaf node. So go ahead and push whichever patch you prefer, and thanks. Jo=C3=A3o