bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23949: 25.0.95; Regression in handling error caused by (string-match


From: Eli Zaretskii
Subject: bug#23949: 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@gmail.com>
> Date: Tue, 12 Jul 2016 18:35:02 +0000
> Cc: 23949@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]