From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daan Ro Newsgroups: gmane.emacs.bugs Subject: bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments Date: Sat, 24 Aug 2024 16:34:08 +0700 Message-ID: <05A6458E-3555-4A3E-B50A-091699481B3B@getmailspring.com> References: <86ikvqnwxm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="66c9a910_253b81fa_139d3" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15552"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "dmitry@gutov.dev" , "72573@debbugs.gnu.org" <72573@debbugs.gnu.org>, Juri Linkov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 24 11:36:31 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 1shnCA-0003q0-Ri for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Aug 2024 11:36:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1shnBv-0006Dl-6c; Sat, 24 Aug 2024 05:36:15 -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 1shnBt-0006DN-Mk for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2024 05:36:13 -0400 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 1shnBt-0007l7-AV for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2024 05:36:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:From:Date:To:Subject; bh=//RWw6Fg0jcHr7QPoMSvM7pdP8Vk+CuNN4xKdjPwJHQ=; b=gXJPcHbtmu3HlVgUMO0YYVdTYHDxv8i5fk5pyEruWo69ST/DyHvPKQzTtkFw4D6tLBb+sFEGAOpHISDrrAan2rMJhtiUY2dmEMu8qGqz1zuEGZUgS67scYnEc80DQ9jjadDuzSGEePXnkwG24nI4RCDMduV51wyMMVYMMWAs3z7yqwBJu9TXT7+/Mqgl0+8NGOlPfUvPpLPtRd/tA3o9iM8KPX9RybbpCBjnbR4feH3ndoHF7gURsvcd1vxgOPxre8+YjRkTf5/7619rsVqNM7RWL28PfW1Z7W6Gwi2O+K3irwcKTXRgxkmuW2d5W75pHMbFYSJxU3n04a4Lh1UaNg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1shnCf-0000Rn-Jx for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2024 05:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daan Ro Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Aug 2024 09:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72573 X-GNU-PR-Package: emacs Original-Received: via spool by 72573-submit@debbugs.gnu.org id=B72573.17244921701646 (code B ref 72573); Sat, 24 Aug 2024 09:37:01 +0000 Original-Received: (at 72573) by debbugs.gnu.org; 24 Aug 2024 09:36:10 +0000 Original-Received: from localhost ([127.0.0.1]:40514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shnBq-0000QT-3z for submit@debbugs.gnu.org; Sat, 24 Aug 2024 05:36:10 -0400 Original-Received: from mail-ot1-f54.google.com ([209.85.210.54]:50554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shnBo-0000QD-0f for 72573@debbugs.gnu.org; Sat, 24 Aug 2024 05:36:09 -0400 Original-Received: by mail-ot1-f54.google.com with SMTP id 46e09a7af769-70943b07c2cso2534761a34.1 for <72573@debbugs.gnu.org>; Sat, 24 Aug 2024 02:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724492053; x=1725096853; darn=debbugs.gnu.org; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=//RWw6Fg0jcHr7QPoMSvM7pdP8Vk+CuNN4xKdjPwJHQ=; b=UgawjNFLgcJyAGK6QdmeMPX6OVvOakOKFCi5Pt5xBNhBt1UkjQ0bkn7JaGmRe4vlbt C1FeO2rW8dHKCFTrR7JCDQu1UAZkJ6xJn/yQ0B182asMEoAhqGqL3phH7M+LrEWlRTZL saSL5xs9QWOT3XT5pW5yHjboWWYbGnEaMRAM/WsW7nw4sM44WJul1U7ivofXyj/L6vtN kv8wIjeKHs96xzAYQ7b9P169GF902s8ZmnseQZCCEkM7Mxpn4efGEZWsk9lRkxpM7IFI Mdza2DiVQMyb1G8gOFeJKr8fyDgs6e/+8c3fuGO4R0ik+NmLQE7jwzOXs5cY49Tj4swh EOWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724492053; x=1725096853; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=//RWw6Fg0jcHr7QPoMSvM7pdP8Vk+CuNN4xKdjPwJHQ=; b=eOd6j1PX4Rmrl966iipgyToZ/ond1UXe3801bEshWtN2/CPDm+toCY4i63CWQN77nC 86EnDRloS+2eMfguqje4FssAZdYZDL9tcKP14MFOQQJxq4r/Y3PophdRY1lhHmWIYM3l ZHJoqlHPGb9PPNG22mWLEAHLX/d+cw9UxiKAsQ4iVrkUtdOOjAXsr2IGICd+6yYAx9rH NW7XxIF6PovAnlzxiyKlrFw/QGKOwp1QmqpPBirowBncdf7V3h8tnHIUWF8Ri8roWSy2 Dpx3I9sTpECogNid07o64xWwKqUkQRKJ9Jq1LtsEsU7D5MIT6zbWofXrM6L2p/RBVA1c 6UgQ== X-Forwarded-Encrypted: i=1; AJvYcCUDGYffPn/w/KKATvj1Irb5T3PbqfdavYV6Vn0HuQG87SkQKjPzGAh6vGJpcBAoyq3UqxHtmw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzQCnzyBLwtrq/uWo9cH+8lVjPWhhQUK1RRfMuQbGZRhC+8w5IJ 1Y37pS7vK2LQqPm9brVO9vR794nw2XXywWyQ0InC3iGOtJtpLtPxAFU6CA== X-Google-Smtp-Source: AGHT+IEKb3vNEQAmUC+2V9lTIde7kQhA0QXAhyy6R0UeG9xBAT+nJTHGN3nuRt0Hal6NtlusCegJnA== X-Received: by 2002:a05:6808:152a:b0:3dc:28c0:ccd5 with SMTP id 5614622812f47-3de2a894380mr6128906b6e.26.1724492052469; Sat, 24 Aug 2024 02:34:12 -0700 (PDT) Original-Received: from dan-laptop ([2405:4802:bfb2:ce40:293f:dfc4:4248:de34]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7cd9ad55880sm3862117a12.69.2024.08.24.02.34.11 for <72573@debbugs.gnu.org> (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 24 Aug 2024 02:34:12 -0700 (PDT) In-Reply-To: <86ikvqnwxm.fsf@gnu.org> X-Mailer: Mailspring 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:290655 Archived-At: --66c9a910_253b81fa_139d3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Juri Linkov's patch is for js-ts-mode so installing it doesn't affect this bug. Since the point is moved in Elisp mode's `(foobar "aaa|" "bbb")` case by default, I think closing this bug is reasonable. But I really hope the behavior is standardized among major modes regardless of using tree sitter or not. Some major modes move, some doesn't, that inconsistency is a little annoying to remember for each language. Maybe we can define a global toggle that affects all major modes, including Emacs-lisp like: (defcustom forward-sexp-constraint-within-strings nil "Disallow `forward-sexp' from moving out of string delimiters.") But that looks like a more general feature request, and probably isn't trivial, too. Daanturo On Aug 24 2024, at 3:32 pm, Eli Zaretskii wrote: > > From: Juri Linkov > > Cc: Eli Zaretskii , 72573@debbugs.gnu.org, daanturo@gmail.com > > Date: Mon, 19 Aug 2024 09:42:50 +0300 > > > > >>>>> I don't think there's much we can do in js-mode (or js-jsx-mode). > > >>>> > > >>>> So you suggest to close this as wontfix? > > >>> > > >>> Probably, yes. > > >>> > > >>> But IIRC we had another bug# where somebody also requested a different > > >>> behavior for forward-sexp. So they could be merged. > > >> Sure, if you know the number, we should merge them. > > > > > > Hmm, forward-sexp's inside strings behavior (and paredit) were last > > > mentioned in https://debbugs.gnu.org/67036#20, but it has a longer list of > > > issues and considerations inside, so maybe not a duplicate. > > > > The solution in bug#67036 was for tree-sitter that in case of > >

just moves out of the string. > > After applying this patch, it will still do the same > > because "string_fragment" is inside quotes, > > while allowing the default behavior inside the string > > because tree-sitter can't look inside: > > > > diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el > > index 75c8111035c..6c1223f36fa 100644 > > --- a/lisp/progmodes/js.el > > +++ b/lisp/progmodes/js.el > > @@ -3929,7 +3929,8 @@ js-ts-mode > > (sexp ,(js--regexp-opt-symbol js--treesit-sexp-nodes)) > > (sentence ,(js--regexp-opt-symbol js--treesit-sentence-nodes)) > > (text ,(js--regexp-opt-symbol '("comment" > > - "template_string")))))) > > + "template_string" > > + "string_fragment")))))) > > > > But since this bug report about the default non-ts behavior, > > I have no idea why the default forward-sexp-function moves to > > the beginning of the next string. Maybe this was implemented > > because the default ad-hoc syntax parsing is not reliable and might > > mix up string beginnings and endings. tree-sitter has no such problem. > > So what is our way forward with this? Should we install the above > patch, or should we close this bug ans wontfix? > --66c9a910_253b81fa_139d3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Juri Linkov's patch is for js-ts-mode so installing it doesn't affec= t
this bug.

Since the point is moved in Elisp mod= e's =60(foobar =22aaa=7C=22 =22bbb=22)=60 case by
default, I th= ink closing this bug is reasonable. But I really hope the
behav= ior is standardized among major modes regardless of using tree
= sitter or not.

Some major modes move, some doesn't, that in= consistency is a little
annoying to remember for each language.= Maybe we can define a global
toggle that affects all major mod= es, including Emacs-lisp like:

(defcustom forward-sexp-cons= traint-within-strings nil
    =22Disallow =60for= ward-sexp' from moving out of string delimiters.=22)

But th= at looks like a more general feature request, and probably isn't
trivial, too.


Daanturo
On Aug 24 2024, at 3:32 pm, Eli Zaretskii <eliz=40= gnu.org> wrote:
> =46rom: Juri Linkov &l= t;juri=40linkov.net>
> Cc: Eli Zaretskii <eliz=40gnu.o= rg>, 72573=40debbugs.gnu.org, daanturo=40gmail.com
> Date= : Mon, 19 Aug 2024 09:42:50 +0300
>
> >>&= gt;>> I don't think there's much we can do in js-mode (or js-jsx-mo= de).
> >>>>
> >>>> So y= ou suggest to close this as wontfix=3F
> >>>
<= div>> >>> Probably, yes.
> >>>
> >>> But IIRC we had another bug=23 where somebody also re= quested a different
> >>> behavior for forward-sexp= . So they could be merged.
> >> Sure, if you know the = number, we should merge them.
> >
> > Hmm= , forward-sexp's inside strings behavior (and paredit) were last
> > mentioned in https://debbugs.gnu.org/67036=2320, but it has a= longer list of
> > issues and considerations inside, so = maybe not a duplicate.
>
> The solution in bug=23= 67036 was for tree-sitter that in case of
> <h1 className= =3D=22cacaca=7C=22> just moves out of the string.
> After= applying this patch, it will still do the same
> because =22= string=5Ffragment=22 is inside quotes,
> while allowing the = default behavior inside the string
> because tree-sitter can= 't look inside:
>
> diff --git a/lisp/progmodes= /js.el b/lisp/progmodes/js.el
> index 75c8111035c..6c1223f36= fa 100644
> --- a/lisp/progmodes/js.el
> +++ b/= lisp/progmodes/js.el
> =40=40 -3929,7 +3929,8 =40=40 js-ts-m= ode
> (sexp ,(js--regexp-opt-symbol js--treesit-sexp-nodes))=
> (sentence ,(js--regexp-opt-symbol js--treesit-sentence-no= des))
> (text ,(js--regexp-opt-symbol '(=22comment=22
<= div>> - =22template=5Fstring=22))))))
> + =22template=5Fs= tring=22
> + =22string=5Ffragment=22))))))
>
> But since this bug report about the default non-ts behavior,=
> I have no idea why the default forward-sexp-function move= s to
> the beginning of the next string. Maybe this was impl= emented
> because the default ad-hoc syntax parsing is not r= eliable and might
> mix up string beginnings and endings. tr= ee-sitter has no such problem.

So what is our way forward w= ith this=3F Should we install the above
patch, or should we clo= se this bug ans wontfix=3F
3D=22Sent --66c9a910_253b81fa_139d3--