bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[Michael Heerdegen]

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)

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[Noam Postavsky]

tags 36067 + unreproducible
quit

Michael Heerdegen <michael_heerdegen@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?

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[Michael Heerdegen]

Noam Postavsky <npostavs@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.

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[Eric Abrahamsen]

Noam Postavsky <npostavs@gmail.com> writes:

> tags 36067 + unreproducible
> quit
>
> Michael Heerdegen <michael_heerdegen@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...

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[Michael Heerdegen]

Eric Abrahamsen <eric@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.

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[martin rudalics]

 > 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

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@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.

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@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

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

bug#36067: 27.0.50; Edebug leaves undefined RET in minibuffer

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.