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#60087: 29.0.60; c++-ts-mode conflict with electric-pair-mode Date: Thu, 15 Dec 2022 21:43:19 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000777ac605efe4bed4" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1458"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eason Huang , casouri@gmail.com, 60087@debbugs.gnu.org To: Daniel =?UTF-8?Q?Mart=C3=ADn?= , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 15 22:44:13 2022 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 1p5w1S-000AdQ-Qa for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Dec 2022 22:44:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5w1N-00068B-CH; Thu, 15 Dec 2022 16:44:05 -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 1p5w1K-00067z-Mk for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2022 16:44:02 -0500 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 1p5w1K-0005zg-DK for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2022 16:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p5w1K-00048J-81 for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2022 16:44:02 -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: Thu, 15 Dec 2022 21:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60087 X-GNU-PR-Package: emacs Original-Received: via spool by 60087-submit@debbugs.gnu.org id=B60087.167114061815870 (code B ref 60087); Thu, 15 Dec 2022 21:44:02 +0000 Original-Received: (at 60087) by debbugs.gnu.org; 15 Dec 2022 21:43:38 +0000 Original-Received: from localhost ([127.0.0.1]:45093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5w0w-00047u-0S for submit@debbugs.gnu.org; Thu, 15 Dec 2022 16:43:38 -0500 Original-Received: from mail-ot1-f46.google.com ([209.85.210.46]:45782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5w0u-00047n-8b for 60087@debbugs.gnu.org; Thu, 15 Dec 2022 16:43:36 -0500 Original-Received: by mail-ot1-f46.google.com with SMTP id l8-20020a056830054800b006705fd35eceso280217otb.12 for <60087@debbugs.gnu.org>; Thu, 15 Dec 2022 13:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ROVe3PuVU6+PK35MRmwAnN7wy4MfWwB91V9KNm/Vius=; b=c0Im+hOP44rFKtGGSZ7H6hCWynwoZ2v6HeaSA94xxySJ53i9PpFq51TP7xsNsecVx6 hTPjsYrCXFm4aRetHsX08J/A04KBdGrkFO70npf6zSyBMbEUqgX6eGjT7BTjQ5XMAeUg DSMJNvT55v/zw2iTC7qV5CXE297pLdYj5yNp2dBr/2GqGzgZOPyInneIm/uYI3oOXK32 1B0IcCDgCywh5Ryk1KYLArMJ+rK+6PX3ytU/T6g3kMjIsjtM0pdPDXghOv5v3LncpbBq k6esdlrqInh7l+jYHjIInxapWeICSlZHepY9Z01pwq/QrV0ymY8i3/yqqfsOJ92tBTD/ GEng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=ROVe3PuVU6+PK35MRmwAnN7wy4MfWwB91V9KNm/Vius=; b=j6G0SEZTAmN0thBVELUsBX6CQKeqyY3G/LpLP9fkPmvmyr+b2j8EeYvaXhrA+5M7DA EDqEA+sGA2peyYNGuNc+/+4pVjR6mCb5vGKhduvzRr6TxOXl+md1mdON7M46ql9T1IOm XTAR497yhx+YCKMZHe7EnELqbEXnENw7+iH98x9LHFSal4digQBzCaClzJLHSd1V5SSV 7eelTAngIY3SNFFRPc3YW7iUineIWO0m0U0TogAkjDdN+jyraye81GYhl35l7ht43ijS gTfRsPTpC3R7P2HuROcnBd82rFy/lzvfrKzRgrOb7iNwEwt0SimjHwXxK6Eqo5LM+skw GahQ== X-Gm-Message-State: ANoB5pmE7bvAmZDmpoeK2pfhGWhyVfqzFtZlLtiFLSL7wXpjOUyuw2XO yuz7e+M//Uj6ZMYnGtxt87zzjOHCx6/21U8qAfE= X-Google-Smtp-Source: AA0mqf6zbHTcvz5FiWQThMCKSFO6j8zNANlSzkuHeQy5Kh2ase7Pu4FTzPt97VbxTaF1Ixn5RhVZ5HZcOcbNP7XPxzI= X-Received: by 2002:a9d:80a:0:b0:670:8334:ccf2 with SMTP id 10-20020a9d080a000000b006708334ccf2mr1367986oty.201.1671140610635; Thu, 15 Dec 2022 13:43:30 -0800 (PST) In-Reply-To: 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:251152 Archived-At: --000000000000777ac605efe4bed4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 15, 2022 at 9:34 PM Daniel Mart=C3=ADn wro= te: > > Jo=C3=A3o T=C3=A1vora writes: > > > I don't know how this can work if '<' is going to be used to input > > the less-than operator. I think more complex syntax-propertization > > functionality is going to be needed here. I don't have a tree-sitter > > build to test, but I'd say that the tree-sitter backend should be asked > > about what kind of '<' and '>' we're talking about. AFAICT, just > > saying that '<' has the delimiter syntax in C++ is wrong. It's not > > like '(' or '{.' > > Yes, you are right. I think for now it's better to consider them as > punctuation. > > A better idea may be to add a syntax-table text property to "<" and ">" > when they define a C++ template (or a Java generic). Tree-sitter can > match something like a "template_argument_list" node easily, but I > wonder how to keep this information in sync with the buffer text in the > most efficient way? Supposedly this is what I understand tree-sitter to be very very good at. My completely naive and absolutely ignorant understanding of the new tree sitter modes is that once you insert something into the buffer, tree sitter is immediately notified, recomputes the syntax tree very efficiently and incrementally, then Emacs can immediately take advantage of that in the `syntax-propertize-function`, applying the correct syntax to each separate manifestation of the '<' and '>' characters. Hopefully all of this runs in time for post-self-insert-hook to see the correct synta= x class and thus electric-pair-mode, which relies on p-s-i-h can do the right thing each time. Again, this is completely my vapourware idea of how all this was implemented. I'll also CC: Stefan who is my syntax-propertize and electric-*-mode sensei. Jo=C3=A3o --000000000000777ac605efe4bed4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 15, 2022 at 9:34 PM Daniel Mart=C3=ADn <mardani29@yahoo.es> wrote:
>= ;
> Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com> writes:
>
> > I don't know= how this can work if '<' is going to be used to input
> &= gt; the less-than operator.=C2=A0 I think more complex syntax-propertizatio= n
> > functionality is going to be needed here.=C2=A0 I don't = have a tree-sitter
> > build to test, but I'd say that the tre= e-sitter backend should be asked
> > about what kind of '<&= #39; and '>' we're talking about.=C2=A0 AFAICT, just
>= > saying that '<' has the delimiter syntax in C++ is wrong. = It's not
> > like '(' or '{.'
>
> = Yes, you are right.=C2=A0 I think for now it's better to consider them = as
> punctuation.
>
> A better idea may be to add a synta= x-table text property to "<" and ">"
> when= they define a C++ template (or a Java generic).=C2=A0 Tree-sitter can
&= gt; match something like a "template_argument_list" node easily, = but I
> wonder how to keep this information in sync with the buffer t= ext in the
> most efficient way?

Supposedly this i= s what I understand tree-sitter to be very very good
at.=C2=A0 My= completely naive and absolutely ignorant understanding of the
ne= w tree sitter modes is that once you insert something into the buffer,=C2= =A0
tree sitter is immediately notified, recomputes the syntax tr= ee very=C2=A0
efficiently and incrementally, then Emacs can immed= iately take advantage=C2=A0
of that in the `syntax-propertize-fun= ction`, applying the correct syntax
to each separate manifestatio= n of the '<' and '>' characters.=C2=A0 Hopefully
all of this runs in time for post-self-insert-hook to see the correct= syntax
class and thus electric-pair-mode, which relies on p-s-i-= h can do the=C2=A0
right thing each time.

Again, this is completely my vapourware idea of how all this was=C2=A0
implemented.=C2=A0 I'll also CC: Stefan who is my syntax-proper= tize
and electric-*-mode sensei.

Jo=C3= =A3o
--000000000000777ac605efe4bed4--