[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: |
Mon, 20 Feb 2023 15:14:07 +0200 |
> Date: Mon, 20 Feb 2023 12:40:54 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca
>
> >> BTW, this makes me wonder why emacs_re_max_failures is not accessible
> >> from Elisp. I think it would be very useful, if only for debugging
> >> purposes. And perhaps let-binding it to a lower value around some
> >> potentially (or actually) problematic regexps would be a good way to
> >> prevent or fix bugs such as the current one.
> >
> > If we know which regexps cause problems, shouldn't we instead fix those
> > regexps, or change how we use them?
> >
>
> If we know how and where to fix them, that's better of course. If we
> don't (and frankly when I look at that regexp I have no idea how it could
> be fixed), limiting the backtracking depth to a more reasonable value is
> better than not fixing the bug.
So let's try fixing the issue that way first, and only fall back to
"limiting failures" if we decide we failed with that.
> > For debugging purposes, you can set the value in the debugger after
> > starting Emacs, or with a breakpoint just before calling the problematic
> > code.
>
> That's only true for the (very) few of us who are comfortable building
> Emacs and running it under GDB (and even for them it's much easier to just
> change the value with a setq). If regexp-max-backtracking-depth had been
> present, everyone could easily have tried to set it to some lower value.
I don't trust people who don't build Emacs and run it under GDB to use
such a variable judiciously.
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, (continued)
- bug#61514: 30.0.50; sadistically long xml line hangs emacs, Eli Zaretskii, 2023/02/19
- 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, Gregory Heytings, 2023/02/19
- 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, Gregory Heytings, 2023/02/19
- 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, 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 <=
- 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, 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, 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