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

[Eli Zaretskii <eliz@gnu.org>]

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