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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: schwab <at> suse.de, 23949 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 25.0.95; Regression in handling error caused by (string-match-p
 "." nil)
Date: Tue, 12 Jul 2016 22:19:34 +0300

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Tue, 12 Jul 2016 18:35:02 +0000
> Cc: 23949 <at> debbugs.gnu.org
> 
>  string-match-p just signals an error, because its 2nd arg must be a
>  string. Look up the backtrace, and you will see that Emacs is trying
>  to signal an error:
> 
> Correct, but that error does not show up within emacs. All the user sees is:
> 
> Entering debugger...
> help-function-arglist: End of file during parsing

Because Emacs hits a second error while trying to show the backtrace
of the first one.

> In any case, I believe that that should not happen.

Indeed, it shouldn't, but the question is: what code is responsible
for that which shouldn't happen?  If some package or your own
customizations cause the debugger to call extra code, and that extra
code signals an error, then that extra code needs to be fixed, not
Emacs.

> Also concerning is the fact that,
> 
> - (string-match "." nil) gives the expected error backtrace.
> - But (string-match-p "." nil) gives the help-function-arglist error. 

Sorry, I fail to see the significance of this to the issue at hand.
They are two different functions, and we still don't know which
functions were advised and how.  Perhaps the advice will explain the
difference.  Or perhaps we understand the reason  for the difference
once we get to the bottom of investigating the problem.  Either way,
the efficient method of looking into this problem is to understand
what are those advices and where do they come from.

Previous Next

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