GNU bug report logs - #36067
27.0.50; Edebug leaves undefined RET in minibuffer

Previous Next

To reply to this bug, email your comments to 36067 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Mon, 03 Jun 2019 04:20:22 +0200

Hi,

sorry, no recipe.  Quite often when I have used edebug, I think often I
killed the session by going to top-level (q), normal RET in the
minibuffer doesn't work any more.  Hitting the key RET does nothing.  I
have to restart Emacs (I need to close it with the mouse or something
like that).

I have no clue why this happens.  Dunno if it is my fault.  Anyone else
seeing this?


Thanks,

Michael.


In GNU Emacs 27.0.50 (build 19, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
 of 2019-06-03 built on drachen
Repository revision: ae7e0657b20037eb386aa21a35f05bcb4c283611
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Debian GNU/Linux 10 (buster)

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 36067 <at> debbugs.gnu.org
Subject: Re: bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Fri, 21 Jun 2019 06:14:09 -0400

tags 36067 + unreproducible
quit

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> sorry, no recipe.  Quite often when I have used edebug, I think often I
> killed the session by going to top-level (q), normal RET in the
> minibuffer doesn't work any more.  Hitting the key RET does nothing.  I
> have to restart Emacs (I need to close it with the mouse or something
> like that).

Do you mean that you're stuck in the minibuffer too?  Or just that the
minibuffer becomes non-functional, while other normal typing still
works.

> I have no clue why this happens.  Dunno if it is my fault.  Anyone else
> seeing this?

Don't think I've ever seen that before.  I know the 'transient' package
(which magit now uses for its popup UI), can have a bad interaction with
edebug when trying to debug its code.  I think it's due to how it messes
with transient keymaps in post/pre comman hooks.  Maybe you have
something similar happen here?

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 36067 <at> debbugs.gnu.org
Subject: Re: bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Fri, 21 Jun 2019 16:59:05 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

> > sorry, no recipe.  Quite often when I have used edebug, I think often I
> > killed the session by going to top-level (q), normal RET in the
> > minibuffer doesn't work any more.  Hitting the key RET does nothing.  I
> > have to restart Emacs (I need to close it with the mouse or something
> > like that).
>
> Do you mean that you're stuck in the minibuffer too?  Or just that the
> minibuffer becomes non-functional, while other normal typing still
> works.

The latter.  I'm not stuck in the minibuffer.  RET not working in the
minibuffer is actually the only symptom.

> > I have no clue why this happens.  Dunno if it is my fault.  Anyone else
> > seeing this?
>
> Don't think I've ever seen that before.  I know the 'transient' package
> (which magit now uses for its popup UI), can have a bad interaction with
> edebug when trying to debug its code.  I think it's due to how it messes
> with transient keymaps in post/pre comman hooks.  Maybe you have
> something similar happen here?

I'll try to find out when I see this the next time.  I tried in the past
but gave up since it was APITA without working minibuffers.

The reason why I created the bug report was that I saw the issue quite
often, while edebugging quite different things.  I hadn't the feeling
that it was specific to the debugged code.  Could still be just Helm
interfering with Edebug or something like that, yes.  Hope I can find
out the next time.

Thanks so far,

Michael.

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Fri, 21 Jun 2019 08:14:19 -0700

Noam Postavsky <npostavs <at> gmail.com> writes:

> tags 36067 + unreproducible
> quit
>
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
>> sorry, no recipe.  Quite often when I have used edebug, I think often I
>> killed the session by going to top-level (q), normal RET in the
>> minibuffer doesn't work any more.  Hitting the key RET does nothing.  I
>> have to restart Emacs (I need to close it with the mouse or something
>> like that).
>
> Do you mean that you're stuck in the minibuffer too?  Or just that the
> minibuffer becomes non-functional, while other normal typing still
> works.
>
>> I have no clue why this happens.  Dunno if it is my fault.  Anyone else
>> seeing this?
>
> Don't think I've ever seen that before.  I know the 'transient' package
> (which magit now uses for its popup UI), can have a bad interaction with
> edebug when trying to debug its code.  I think it's due to how it messes
> with transient keymaps in post/pre comman hooks.  Maybe you have
> something similar happen here?

I may have seen something similar, where there seems to be an cursor in
the minibuffer, sort of like a prompt with no text, but you can't "get
there" to quit the prompt. I've found that `exit-recursive-edit' gets
out of it. Ignore me if this is unrelated...

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 36067 <at> debbugs.gnu.org
Subject: Re: bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Fri, 21 Jun 2019 17:59:02 +0200

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> I may have seen something similar, where there seems to be an cursor in
> the minibuffer, sort of like a prompt with no text, but you can't "get
> there" to quit the prompt. I've found that `exit-recursive-edit' gets
> out of it. Ignore me if this is unrelated...

Yes, seems unrelated ;-) as it's quite different from what I see.  FWIW,
I think I sometimes see what you describe when there is an active
minibuffer in another frame.

Michael.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>, 36067 <at> debbugs.gnu.org
Subject: Re: bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Sat, 22 Jun 2019 10:22:41 +0200

> I may have seen something similar, where there seems to be an cursor in
> the minibuffer, sort of like a prompt with no text, but you can't "get
> there" to quit the prompt. I've found that `exit-recursive-edit' gets
> out of it. Ignore me if this is unrelated...

It's quite easy to confuse Emacs by selecting the minibuffer window
without activating the minibuffer.  With Emacs -Q evaluate

(select-window (minibuffer-window))

Here I now can't get out the minibuffer window via C-g nor C-M-c
(there's no recursive editing in progress) or some key I bind
'abort-recursive-edit' to - C-] being non-functional on my keyboard -
(again because there's not recursive editing in progress).

M-x ESC does nothing.  Plain ESC ESC ESC gets me (with
'debug-on-error' set)

(error "Window nil is a minibuffer window")
  signal(error ("Window nil is a minibuffer window"))
  error("Window %s is a minibuffer window" nil)
  switch-to-prev-buffer(nil bury)
  bury-buffer()
  keyboard-escape-quit()
  funcall-interactively(keyboard-escape-quit)
  call-interactively(keyboard-escape-quit nil nil)
  command-execute(keyboard-escape-quit)

M-ESC is handled by the OS.

The only things that work here are M-x quit which then displays the
*Messages* buffer and one of M-x ESC ESC ESC, M-x keyboard-quit and
M-x keyboard-escape-quit which all get me back to *scratch*.

Also, selecting another window by clicking into it with the mouse
works.  Things do get worse when the minibuffer is on another (maybe
iconified, invisible ...) frame.

So we'd have to check whether the behavior the OP sees is just some
such looping as I described above or something rooted deeper in the
edebug code.

martin

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 36067 <at> debbugs.gnu.org
Subject: Re: bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Tue, 09 Jul 2019 04:08:05 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> > Don't think I've ever seen that before.  I know the 'transient'
> > package (which magit now uses for its popup UI), can have a bad
> > interaction with edebug when trying to debug its code.  I think it's
> > due to how it messes with transient keymaps in post/pre comman
> > hooks.  Maybe you have something similar happen here?
>
> I'll try to find out when I see this the next time.

I saw it again.  This time indeed a left over transient-map was the
culprit.  The transient-map had been installed with `set-transient-map'
with a KEEP-PRED that should have been failing, but somehow, due to the
interaction with edebug, or just the recursive edit, the transient map
stayed alive, I guess the KEEP-PRED was not tested anymore, but I'm not
sure.  It's not easy to reproduce the issue at will, so I have a hard
time to find out more.

Michael.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 36067 <at> debbugs.gnu.org
Subject: Re: bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Tue, 10 Aug 2021 18:11:50 +0200

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> I may have seen something similar, where there seems to be an cursor in
> the minibuffer, sort of like a prompt with no text, but you can't "get
> there" to quit the prompt. I've found that `exit-recursive-edit' gets
> out of it. Ignore me if this is unrelated...

Yes, I've seen similar behaviour -- I've never been able to reproduce
how it happens, but it's usually to do with entering edebug/a backtrace,
and then doing something else, and then `C-g'-ing out of something, and
then Emacs is in this weird state.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: 36067 <at> debbugs.gnu.org
Subject: Re: bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Sun, 21 Apr 2024 06:24:26 +0200

Hello,

Something that might be related:

If you edebug some code that uses `unwind-protect' to ensure certain
cleanup things are done, and you quit Edebug before those protected
forms are reached, they will never be executed.  This can break your
session in diverse surprising ways.

Here is a harmless example to demonstrate what I mean:

#+begin_src emacs-lisp
(defvar a 0)

(unwind-protect
    (progn (setq a 27)
           (message "%d" (+ a 19)))
  (setq a 0))
#+end_src

When you edebug the `unwind-protect' form and hit q (quit) when the
`message' call has been reached, your session will remain with a binding
of 27 for a - which is normally impossible and should never happen.

Quitting Edebug is a very dangerous operation for an Emacs session.


Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife
 of text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 36067 <at> debbugs.gnu.org
Subject: Re: bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer
Date: Sun, 21 Apr 2024 08:02:33 +0200

I had written:

> #+begin_src emacs-lisp
> (defvar a 0)
>
> (unwind-protect
>     (progn (setq a 27)
>            (message "%d" (+ a 19)))
>   (setq a 0))
> #+end_src
>
> When you edebug the `unwind-protect' form and hit q (quit) when the
> `message' call has been reached, your session will remain with a binding
> of 27 for a - which is normally impossible and should never happen.

Although - I apologize - this is not what is happening: Edebug always
stops at the unwind forms.

I guess what I always do is thinking: "I said quit, why does it stop
again?" and quit again - which then explicitly skips the execution of
any unwind forms - bad for me.

So: should quitting maybe also set the mode to something like Go-nonstop
before calling `top-level' - would that behave better?


Michael.

Previous Next

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