[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49675: 28.0.50; minibuffer-quit produces error
From: |
Lars Ingebrigtsen |
Subject: |
bug#49675: 28.0.50; minibuffer-quit produces error |
Date: |
Wed, 21 Jul 2021 16:20:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Pankaj Jangid <pankaj@codeisgreat.org> writes:
> I could reproduce this with just
>
> (setq debug-on-error t)
>
> in my ~/emacs.d/init.el. The steps are:
>
> 1. emacs -Q
> 2. eval (setq debug-on-error t)
> 3. M-x C-g
Thanks; I can reproduce it with that recipe. I think the problem may be
here:
static bool
maybe_call_debugger (Lisp_Object conditions, Lisp_Object sig, Lisp_Object data)
{
Lisp_Object combined_data;
combined_data = Fcons (sig, data);
if (
/* Don't try to run the debugger with interrupts blocked.
The editing loop would return anyway. */
! input_blocked_p ()
&& NILP (Vinhibit_debugger)
/* Does user want to enter debugger for this kind of error? */
&& (EQ (sig, Qquit)
? debug_on_quit
: wants_debugger (Vdebug_on_error, conditions))
I guess it should check whether it's an error symbol that inherits from
Qquit instead of testing for Qquit... I'll take a poke at that and see
whether there's more of these.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no