GNU bug report logs - #61514
30.0.50; sadistically long xml line hangs emacs

Previous Next

Full log

Message #104 received at 61514 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: mah <at> everybody.org, 61514 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs
Date: Mon, 20 Feb 2023 14:31:07 +0200

> Date: Sun, 19 Feb 2023 23:58:41 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: mah <at> everybody.org, 61514 <at> debbugs.gnu.org, 
>     Stefan Monnier <monnier <at> 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?

For debugging purposes, you can set the value in the debugger after
starting Emacs, or with a breakpoint just before calling the
problematic code.

As you have seen from the history of this value, it's problematic to
calculate, and the meaning of the value is not obvious.  So exposing
this to Lisp would be a rope that's too long to give our users and
programmers.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.