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