[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61514: 30.0.50; sadistically long xml line hangs emacs
From: |
Stefan Monnier |
Subject: |
bug#61514: 30.0.50; sadistically long xml line hangs emacs |
Date: |
Mon, 20 Feb 2023 08:19:26 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>> IIUC the above describes the code where we're stuck inf-looping inside
>> `looking-at`?
> Not inflooping, but very slowly backtracking, or so it seems.
Duh, right. I meant "hang". Sorry for being a bit mushy-brained for a moment.
>> Is it the same place where the regexp-stack overflow happens (and with
>> the same regexp)?
>
> It's (almost) the same place, but not the same regexp. The regexp
> which causes the stack-overflow message (which is emitted from
> set-auto-mode, before entering redisplay) is this:
>
>
> "\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[
> \r\t\n]*=\\(?:[
> \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([
> \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?"
>
> As you can see, the prepended "[^<>\n]+?" in the regexp which "hangs"
> makes all the difference. So the looking-at which fails reasonably
> quickly is the first call to looking-at above, whereas the one the
> "hangs" is the second one.
Yes, it makes a lot of sense now.
> Maybe this points out a way out of this misery?
I think it does. E.g. there's a chance that using "[^<>\n]+?\\<"
instead of "[^<>\n]+?" avoids the hang (not sure if it's the right
thing to do for all the regexp that can be returned by
`xmltok-attribute`, tho).
And for the stack overflow I haven't yet found its origin.
Stefan
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, (continued)
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Gregory Heytings, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Eli Zaretskii, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Eli Zaretskii, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Gregory Heytings, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Eli Zaretskii, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Gregory Heytings, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Gregory Heytings, 2023/02/19
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Eli Zaretskii, 2023/02/20
bug#61514: 30.0.50; sadistically long xml line hangs emacs, Stefan Monnier, 2023/02/19
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Eli Zaretskii, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs,
Stefan Monnier <=
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Eli Zaretskii, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Stefan Monnier, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Gregory Heytings, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Stefan Monnier, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Gregory Heytings, 2023/02/20
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Gregory Heytings, 2023/02/20
bug#61514: 30.0.50; sadistically long xml line hangs emacs, Stefan Monnier, 2023/02/20
bug#61514: 30.0.50; sadistically long xml line hangs emacs, Gregory Heytings, 2023/02/20
bug#61514: 30.0.50; sadistically long xml line hangs emacs, Stefan Monnier, 2023/02/20
bug#61514: 30.0.50; sadistically long xml line hangs emacs, Stefan Monnier, 2023/02/20