GNU bug report logs - #23949
25.0.95; Regression in handling error caused by (string-match-p "." nil)

Previous Next

Full log

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

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: schwab <at> suse.de, Eli Zaretskii <eliz <at> gnu.org>, 23949 <at> debbugs.gnu.org
Subject: Re: 25.0.95; Regression in handling error caused by (string-match-p
 "." nil)
Date: Wed, 13 Jul 2016 13:10:46 +0000

[Message part 1 (text/plain, inline)]

On Tue, Jul 12, 2016 at 4:27 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:

> Clearly, the problem is that string-match-p uses
> "(let ((inhibit-changing-match-data t))", so the debugger is run with
> inhibit-changing-match-data bound to t and that breaks lots of
> Elisp code.
>
> That's a general problem with the use dynamic binding to pass extra
> parameters: you end up passing them not just to that one function but
> also to all other functions called from that one.
>

Thanks Stefan.

So what is the way forward?

Fixing just string-match-p and string-match does not seem to the complete
solution, because I have seen just let-bound dynamic vars at many places.

As I posted in the emacs-devel thread (
https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00544.html ),
while this string-match-p issue causes a confusing seemingly unrelated
error, some other packages cause emacs to freeze up (check the drag-stuff
example in the above link). When I get a change I will add a minimum
working example for the drag-stuff package causing emacs freeze too.

Certainly there was a lower level change after emacs 24.5 that changed the
behavior of how the run-hooks behave or how the advices are executed in
general or when called within a debugger?
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Previous Next

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