bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#61514: 30.0.50; sadistically long xml line hangs emacs
Date: Tue, 21 Feb 2023 14:05:40 +0200

> Date: Mon, 20 Feb 2023 20:13:38 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 61514@debbugs.gnu.org, mah@everybody.org
> 
> > 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]