Daanturo |
> 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 abovepatch, or should we close this bug ans wontfix?