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

[Eli Zaretskii]

> 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.