From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#62086: 29.0.60; ruby-ts-mode regressions Date: Wed, 12 Apr 2023 15:11:52 -0700 Message-ID: References: <86y1o5op2v.fsf@mail.linkov.net> <5abcf765-f8ce-9563-63aa-20c558409898@yandex.ru> <86cz4l7zjk.fsf@mail.linkov.net> <86ttxww12o.fsf@mail.linkov.net> <865yaakfs7.fsf@mail.linkov.net> <0bd5f2b8-6f0b-09d6-6240-38c742eca19f@yandex.ru> <861qkyfg8l.fsf@mail.linkov.net> <9ceb589f-9325-1607-d1b5-5fd56cb8c3ec@yandex.ru> <86y1myxsrq.fsf@mail.linkov.net> <263c2966-acff-436a-43fd-20f9da8986fb@yandex.ru> <1df48560-a14c-9414-5e9e-97b5109e4aa4@yandex.ru> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) 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="2371"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62086@debbugs.gnu.org, Theodor Thornhill , Juri Linkov To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 13 00:13:23 2023 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 1pmiiR-0000Oh-Af for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Apr 2023 00:13:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmiiC-0007wg-5X; Wed, 12 Apr 2023 18:13:08 -0400 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 1pmii6-0007tn-WE for bug-gnu-emacs@gnu.org; Wed, 12 Apr 2023 18:13:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pmii6-0003Gz-NJ for bug-gnu-emacs@gnu.org; Wed, 12 Apr 2023 18:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmii5-0002qW-WD for bug-gnu-emacs@gnu.org; Wed, 12 Apr 2023 18:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Apr 2023 22:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62086 X-GNU-PR-Package: emacs Original-Received: via spool by 62086-submit@debbugs.gnu.org id=B62086.168133753310876 (code B ref 62086); Wed, 12 Apr 2023 22:13:01 +0000 Original-Received: (at 62086) by debbugs.gnu.org; 12 Apr 2023 22:12:13 +0000 Original-Received: from localhost ([127.0.0.1]:42038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmihJ-0002pM-43 for submit@debbugs.gnu.org; Wed, 12 Apr 2023 18:12:13 -0400 Original-Received: from mail-pl1-f176.google.com ([209.85.214.176]:34738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmihG-0002p5-4H for 62086@debbugs.gnu.org; Wed, 12 Apr 2023 18:12:11 -0400 Original-Received: by mail-pl1-f176.google.com with SMTP id h24so13113181plr.1 for <62086@debbugs.gnu.org>; Wed, 12 Apr 2023 15:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681337524; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wx86c6vT5sEwZLfV3LB9oBGvtkkiMMLAtccE6towOMM=; b=HRBLoU65RRNalzQDPGk7DARnxi6YelMRRKWgIdhodsVrJd5/mIBfsvPJJO0xxqGVbY 6fdtRKyaQi4CxzMghaWlOLfClCXtRdxdoRQPdpe1U5DHeLsrebgCJXVdTOTgp8YhmpqE swJgLeicOggl0HLIKOiofVh7dOPTmq5JOTBLGqI8DYYTLeTj4Z1mk9Y2X6C3V/GEoiao JQeuvrAq5hEO1Lhc6hC19a9ZAkXzXMyE1ybCy0m+2qBbQPhKXLWZcWL4mSzfLAcTw3Tp eFUKZznJ1uxuZdkcfsoYtuy0t2WlGdaQZoHy+ytiHykA4c+ATWzfzLAoNb6H4hpIr9Xv 1/qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681337524; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wx86c6vT5sEwZLfV3LB9oBGvtkkiMMLAtccE6towOMM=; b=HUKf6EHxSgOwZNy2r7Q2WAoNPQBOzi0+Ig263OXkHWtIP5PsWnEkByd4gWYO+SOYV7 lhgTHkdPm9IaafQf1pqXXdZJFCvG8zV6JPu4uxK1cKPQ0JMVNhaxwsfig6B++S575rDY 3t/VNiFDycw2fo0CxmKXiy5ipbSXfMYC16cIdnPYaZN7opAf8ql/79VMxG+CJgX8cwSL TL3sYcqvpnU7Ho1bJmoc0zeMc2Rl+pT2qeKspWHkpfsXTzbAPn45dfVuHUEC4w4dz3gS FJRsWk2+ABBfk9XUXG9+VycfpfKmLeKK+6MVX7exh3ywiIgctmn9vcNqNKoCv2UdazFI 1XtA== X-Gm-Message-State: AAQBX9d3P9tgjoTZHUtVJVx/xJeScPDtRsM5pjYhiIjknESkia31pxeo UYi5ub7g2d/Nb76JUVpRP4k= X-Google-Smtp-Source: AKy350a/V/Z1XKOgzqJNuQiN9xTT/gkxV1zZk3f6Kej7j2Ow1HbzrV0q3N4cFIpQe+wmrSx56E1Pdw== X-Received: by 2002:a17:90a:294e:b0:246:882f:e28a with SMTP id x14-20020a17090a294e00b00246882fe28amr793739pjf.13.1681337523987; Wed, 12 Apr 2023 15:12:03 -0700 (PDT) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id e6-20020a170902d38600b001966d94cb2esm53774pld.288.2023.04.12.15.12.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2023 15:12:03 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3731.500.231) 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:259817 Archived-At: > On Apr 12, 2023, at 2:56 PM, Dmitry Gutov wrote: >=20 > On 13/04/2023 00:50, Yuan Fu wrote: >>> On Apr 12, 2023, at 1:13 PM, Dmitry Gutov wrote: >>>=20 >>> On 12/04/2023 18:31, Dmitry Gutov wrote: >>>> On 12/04/2023 10:05, Yuan Fu wrote: >>>>> Actually, would it make sense to define sexp as =E2=80=9Canything = but some very small punctuation and delimiters=E2=80=9D? >>>> Pretty much. If I understood you correctly. >>>> E.g. in ruby-ts-mode identifiers and numbers are also sexps. >>>=20 >>> Allow me to update that. >>>=20 >>> =46rom the previous threads, for ruby-ts-mode at least, we seem to = have concluded that it's best to treat those nodes as sexps which have = visible boundaries that are visible and don't overlay exactly the = boundaries of the contained nodes. >>>=20 >>> For example, we now exclude statement nodes and binary expression = nodes because both make forward/backward-sexp less obvious and = predictable: you move point to the beginning of 'a + b', press C-M-f, = and if the jump happens over the whole expression, this is just as = likely to mismatch the user's intention (which might have wanted to only = jump over 'a'). So these are the node we rule out. >> User might as well want to move over the whole expression, since they = can use forward-word if they want to move over smaller elements. But I = guess that=E2=80=99s just personal preferences. >=20 > forward-word works for minor elements, but the sub-expression can be, = for example, a parenthesized expression (with "real" parens). >=20 > It's definitely something that can be discussed, but the above = guideline seems to me like something that puts the user more in control. = Because as handy jumping over statements can be, it's usually not what = one is trying to do. >=20 >>> The easiest choice would be to go back to treating only = braces/brackets/parens are sexp delimiters, but in Ruby, at least, we = have lots of constructs that are delimited with keywords (such as 'if', = 'def', 'end'), so that doesn't work. Maybe it'll work better in C/C++, = where you mostly need to be able to differentiate between different = types of angle brackets. >> To clarify, my point is to define sexp by exclusion rather than = inclusion, ie, defining a set of nodes that are not sexp, rather than = defining a set of nodes that are sexp. I mentioned delimiters because = they are excluded from sexp, not because they delimit sexp. >=20 > Yes, that can work. Only when the excluded type names a one-char long, = though, because Elisp has no lookahead. In ruby-ts-mode there are longer = excluded types. Actually, I=E2=80=99m working on extending the =E2=80=9Cpattern=E2=80=9D = treesit-search-forward and friends can accept. Right now it has to be a = regexp or a pred function. I plan to extend it to regexp | function | = (regexp . function) | (or =E2=80=A6) | (not =E2=80=A6) = | (verbatim string) I=E2=80=99m not yet sure about the performance implication of the = recursive patterns (or and not). And I=E2=80=99m not sure if verbatim is = necessary, but I guess having it wouldn=E2=80=99t hurt. Yuan=