bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Daan Ro]

[-- Attachment #1: Type: text/plain, Size: 4883 bytes --]

Unexpected forward-sexp behavior at the end of strings in JSX fragments

* Reproduce
1. Create file.jsx:

```jsx
function Foo() {
// cursor at the end of "cacaca", `forward-sexp-default-function'
return (
<div>
<h1 className="cacaca|">
hello world
<h2 id="h2-id"></h2>
</h1>
</div>
);
}

```
2. Put cursor at the end of "cacaca" (before the closing double quote)
3. `C-M-f`/`forward-sexp`

* Observed: Cursor moves to the beginning of "h2-id".
* Expected: Cursor stays without moving.

In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.42,
cairo version 1.18.0)
System Description: Arch Linux

Configured using:
'configure --with-pgtk --with-native-compilation=aot --sysconfdir=/etc
--prefix=/usr --libexecdir=/usr/lib --with-tree-sitter
--localstatedir=/var --with-cairo --disable-build-details
--with-harfbuzz --with-libsystemd --with-modules 'CFLAGS=-march=x86-64
-mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3
-Wformat -Werror=format-security -fstack-clash-protection
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'
'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro
-Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto'
'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
value of $LANG: en_GB.UTF-8
value of $XMODIFIERS: @im=fcitx
locale-coding-system: utf-8-unix

Major mode: JavaScript[JSX]
Minor modes in effect:
winner-mode: t
savehist-mode: t
recentf-mode: t
minibuffer-depth-indicate-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
electric-pair-mode: t
delete-selection-mode: t
cua-mode: t
fido-vertical-mode: t
icomplete-vertical-mode: t
icomplete-mode: t
fido-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
context-menu-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp comp-cstr
warnings icons rx cl-extra help-mode vc-git diff-mode easy-mmode
vc-dispatcher js c-ts-common treesit json subr-x map byte-opt bytecomp
byte-compile imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs emacs-my-q winner ring savehist
recentf tree-widget wid-edit mb-depth display-line-numbers elec-pair
delsel cua-base icomplete my-functions-for--quick cl-seq cl-macs gv
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win pgtk-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 143066 6481)
(symbols 48 11130 0)
(strings 32 33669 1919)
(string-bytes 1 1198850)
(vectors 16 22493)
(vector-slots 8 439310 15535)
(floats 8 52 38)
(intervals 56 469 0)
(buffers 984 13))

Daanturo


[-- Attachment #2: Type: text/html, Size: 7400 bytes --]

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Eli Zaretskii]

> Date: Sun, 11 Aug 2024 16:33:28 +0700
> From: Daan Ro <daanturo@gmail.com>
> 
> Unexpected forward-sexp behavior at the end of strings in JSX fragments
> 
> * Reproduce
> 1. Create file.jsx:
> 
> ```jsx
> 
> function Foo() {
>   // cursor at the end of "cacaca", `forward-sexp-default-function'
>   return (
>     <div>
>       <h1 className="cacaca|">
>         hello world
>         <h2 id="h2-id"></h2>
>       </h1>
>     </div>
>   );
> }
> 
> ```
> 
> 2. Put cursor at the end of "cacaca" (before the closing double quote)
> 3. `C-M-f`/`forward-sexp`
> 
> * Observed: Cursor moves to the beginning of "h2-id".

Here it moves to after the opening quotes of <h1 className="cacaca|">.
This is in Emacs 30.  Looks like some mistake in handling the syntax
of the starting position?

> * Expected: Cursor stays without moving.

Dmitry, could you have a look, please?

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Dmitry Gutov]

Hi!

On 15/08/2024 10:54, Eli Zaretskii wrote:
>> Date: Sun, 11 Aug 2024 16:33:28 +0700
>> From: Daan Ro <daanturo@gmail.com>
>>
>> Unexpected forward-sexp behavior at the end of strings in JSX fragments
>>
>> * Reproduce
>> 1. Create file.jsx:
>>
>> ```jsx
>>
>> function Foo() {
>>    // cursor at the end of "cacaca", `forward-sexp-default-function'
>>    return (
>>      <div>
>>        <h1 className="cacaca|">
>>          hello world
>>          <h2 id="h2-id"></h2>
>>        </h1>
>>      </div>
>>    );
>> }
>>
>> ```
>>
>> 2. Put cursor at the end of "cacaca" (before the closing double quote)
>> 3. `C-M-f`/`forward-sexp`
>>
>> * Observed: Cursor moves to the beginning of "h2-id".
> 
> Here it moves to after the opening quotes of <h1 className="cacaca|">.
> This is in Emacs 30.  Looks like some mistake in handling the syntax
> of the starting position?

In my testing it moves like the report says: to the beginning of h2-id.

Maybe you skipped step 2?

>> * Expected: Cursor stays without moving.
> 
> Dmitry, could you have a look, please?

I don't think there's much we can do in js-mode (or js-jsx-mode).

And it's relatively normal for forward-sexp to jump between strings 
literals anyway - you can try the same with Elisp and code like

   (foobar "aaa|" "bbb")

To note, with paredit-mode the behavior of C-M-f is altered, and it 
moves to just after the first closing ". We might consider doing the 
same for forward-sexp when it's used interactively.

Also FWIW in js-ts-mode (the tree-sitter mode) C-M-f also does that, but 
I'd say that's just a side-effect of its current implementation (of sexp 
navigation), and it might change in the future.

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Eli Zaretskii]

> Date: Sun, 18 Aug 2024 16:37:03 +0300
> Cc: 72573@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> 2. Put cursor at the end of "cacaca" (before the closing double quote)
> >> 3. `C-M-f`/`forward-sexp`
> >>
> >> * Observed: Cursor moves to the beginning of "h2-id".
> > 
> > Here it moves to after the opening quotes of <h1 className="cacaca|">.
> > This is in Emacs 30.  Looks like some mistake in handling the syntax
> > of the starting position?
> 
> In my testing it moves like the report says: to the beginning of h2-id.
> 
> Maybe you skipped step 2?

No, I haven't.

> >> * Expected: Cursor stays without moving.
> > 
> > Dmitry, could you have a look, please?
> 
> 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?

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Dmitry Gutov]

On 18/08/2024 16:42, Eli Zaretskii wrote:
>> Date: Sun, 18 Aug 2024 16:37:03 +0300
>> Cc: 72573@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>>> 2. Put cursor at the end of "cacaca" (before the closing double quote)
>>>> 3. `C-M-f`/`forward-sexp`
>>>>
>>>> * Observed: Cursor moves to the beginning of "h2-id".
>>>
>>> Here it moves to after the opening quotes of <h1 className="cacaca|">.
>>> This is in Emacs 30.  Looks like some mistake in handling the syntax
>>> of the starting position?
>>
>> In my testing it moves like the report says: to the beginning of h2-id.
>>
>> Maybe you skipped step 2?
> 
> No, I haven't.

At the end of step 2 the cursor is already close to the end of

   <h1 className="cacaca|">

(the character | denoted its position). So C-M-f can't move it to the 
opening quote of this tag - that would be the opposite direction of 
where it's supposed to move.

>>>> * Expected: Cursor stays without moving.
>>>
>>> Dmitry, could you have a look, please?
>>
>> 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.

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Eli Zaretskii]

> Date: Sun, 18 Aug 2024 17:11:44 +0300
> Cc: daanturo@gmail.com, 72573@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 18/08/2024 16:42, Eli Zaretskii wrote:
> >> Date: Sun, 18 Aug 2024 16:37:03 +0300
> >> Cc: 72573@debbugs.gnu.org
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >>
> >>>> 2. Put cursor at the end of "cacaca" (before the closing double quote)
> >>>> 3. `C-M-f`/`forward-sexp`
> >>>>
> >>>> * Observed: Cursor moves to the beginning of "h2-id".
> >>>
> >>> Here it moves to after the opening quotes of <h1 className="cacaca|">.
> >>> This is in Emacs 30.  Looks like some mistake in handling the syntax
> >>> of the starting position?
> >>
> >> In my testing it moves like the report says: to the beginning of h2-id.
> >>
> >> Maybe you skipped step 2?
> > 
> > No, I haven't.
> 
> At the end of step 2 the cursor is already close to the end of
> 
>    <h1 className="cacaca|">
> 
> (the character | denoted its position). So C-M-f can't move it to the 
> opening quote of this tag - that would be the opposite direction of 
> where it's supposed to move.

I expected it to move out of the tag or to the next tag/element.

> >> 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.

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Dmitry Gutov]

On 18/08/2024 17:16, Eli Zaretskii wrote:

>>>> 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.

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Juri Linkov]

>>>>> 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
<h1 className="cacaca|"> 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.

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  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
> <h1 className="cacaca|"> 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?

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Daan Ro]

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

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 <eliz@gnu.org> wrote:
> > From: Juri Linkov <juri@linkov.net>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 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
> > <h1 className="cacaca|"> 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?
>


[-- Attachment #2: Type: text/html, Size: 4283 bytes --]

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Eli Zaretskii]

> Date: Sat, 24 Aug 2024 16:34:08 +0700
> From: Daan Ro <daanturo@gmail.com>
> Cc: Juri Linkov <juri@linkov.net>, "dmitry@gutov.dev"
>  <dmitry@gutov.dev>, "72573@debbugs.gnu.org"
>  <72573@debbugs.gnu.org>
> 
> 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.

Does anyone object to closing this as wontfix?  I will wait for
objections for another week, and close then if no objections voiced.

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Juri Linkov]

>> @@ -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?

I pushed the above patch with small changes to master.

Since the report was about non-ts modes, and it's not easy to change
the default behavior, probably this can be closed as wontfix.

bug#72573: 29.4; js-mode/JSX: forward-sexp behavior at end of string in JSX fragments

[Eli Zaretskii]

tags 72573 wontfix
thanks

> From: Juri Linkov <juri@linkov.net>
> Cc: dmitry@gutov.dev,  72573@debbugs.gnu.org,  daanturo@gmail.com
> Date: Sun, 01 Sep 2024 20:02:29 +0300
> 
> >> @@ -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?
> 
> I pushed the above patch with small changes to master.
> 
> Since the report was about non-ts modes, and it's not easy to change
> the default behavior, probably this can be closed as wontfix.

No further comments within 2 weeks, so I'm now closing this bug.