GNU bug report logs -
#61514
30.0.50; sadistically long xml line hangs emacs
Previous Next
Reported by: "Mark A. Hershberger" <mah <at> everybody.org>
Date: Tue, 14 Feb 2023 21:05:02 UTC
Severity: normal
Found in version 30.0.50
Done: Gregory Heytings <gregory <at> heytings.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
>
> BTW, personally when I suggested to limit the search I was thinking of
> `narrow-to-region` (which bounds both N factors in the N² complexity).
>
Indeed, that's another way to cope with that problem, and a better one:
diff --git a/lisp/nxml/xmltok.el b/lisp/nxml/xmltok.el
index c36d225c7c9..9badd7e4c53 100644
--- a/lisp/nxml/xmltok.el
+++ b/lisp/nxml/xmltok.el
@@ -734,8 +734,10 @@ xmltok-scan-attributes
(atts-needing-normalization nil))
(while (cond ((or (looking-at (xmltok-attribute regexp))
;; use non-greedy group
- (when (looking-at (concat "[^<>\n]+?"
- (xmltok-attribute regexp)))
+ (when (with-restriction
+ (point) (+ (point) 10000)
+ (looking-at (concat "[^<>\n]+?"
+ (xmltok-attribute regexp))))
(unless recovering
(xmltok-add-error "Malformed attribute"
(point)
With this opening the 4 MB file takes 1.6 seconds. With 5000 instead of
10000 it takes 0.8 seconds.
>
> AFAIK this part of the code is intended mostly when editing XML by hand,
> where attributes aren't expected to be ridiculously long, so limiting to
> a few kB would be perfectly acceptable (and if the search fails it's not
> big deal: when the search succeeds we don't *really* know what it means
> either, it may be a false positive anyway).
>
Indeed.
This bug report was last modified 2 years and 147 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.