Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs

From: Eli Zaretskii <[email-masked]>
Date: Tue, 21 Feb 2023 14:05:40 +0200

> Date: Mon, 20 Feb 2023 20:13:38 +0000
> From: Gregory Heytings <[email-masked]>
> cc: Eli Zaretskii <[email-masked]>, [email-masked], [email-masked]
> 
> > Maybe we should reduce the scope of the search for the fallback case 
> > (the case where we add the "[^...]+\\<" prefix) since AFAICT its only 
> > purpose is to try and guess a helpful error messages when the XML is 
> > ill-formed.
> >
> 
> That's an idea, yes.  With the following patch even your "n_n_..." example 
> opens almost instantanously:
> 
> diff --git a/lisp/nxml/xmltok.el b/lisp/nxml/xmltok.el
> index c36d225c7c9..61783ea4dec 100644
> --- a/lisp/nxml/xmltok.el
> +++ b/lisp/nxml/xmltok.el
> @@ -734,7 +734,7 @@ xmltok-scan-attributes
>          (atts-needing-normalization nil))
>       (while (cond ((or (looking-at (xmltok-attribute regexp))
>                        ;; use non-greedy group
> -                     (when (looking-at (concat "[^<>\n]+?"
> +                     (when (looking-at (concat "[^<>\n]\\{1,1000\\}?\\<"
>                                                  (xmltok-attribute regexp)))

SGTM, but isn't 1000 a somewhat low value?  What if we use half of the
value of long-line-optimizations-region-size instead?