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

[Gregory Heytings]

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

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