bug#48249: 28.0.50; Regression: emacs confused about window configuration due to ido-mode and/or winner-mode

[Dima Kogan]

Hi. I'm running a bleeding-edge build of emacs, and I've been observing
a really annoying behavior regression for the last few months. It was
somewhat elusive, but I finally just figured out how to reproduce it, so
I'm now reporting the bug.

Emacs periodically gets into a confused state, where simple commands
like (switch-to-other-buffer) start doing strange things (switching to
the wrong buffer, messing with the window configuration, etc). And the
point often gets stuck in the minibuffer, requiring an explicit switch
command to get out of there. Killing that emacs frame, and starting a
new one (I'm using the emacs server) would fix it for the new frame for
a while, until that frame gets confused too.

I haven't tried to rebuild today, but this bug exists in the emacs git
as of May 1.

Recipe:

1. emacs -Q --eval "(progn (ido-mode 'buffers) (winner-mode))"

   I believe both of those modes are required to tickle the bug. Emacs
   comes up with one big window visiting the *scratch* buffer

2. C-x b RET

   Switch to a different buffer. Here we moved to the default choice:
   the *Messages* buffer

3. C-c LEFT

   Ask winner-mode to go back to the previous window state. We're now
   visiting the *scratch* buffer again

4. M-x

   Ask emacs to interactively run some command. We move to the
   minibuffer, where we can type the command we want

5. C-g

   Never mind. Emacs should now cancel the M-x interactive command
   entry, and jump back to the *scratch* buffer.

But due to this bug, the point sticks in the minibuffer, and you have to
C-x o to get it out. At this point any C-g of any minibuffer anything
will get stuck. And other weirdness will happen in this frame.

I haven't done any debugging yet. Finding the case of the problem and
the recipe is the most important thing here, I think. If this doesn't
speak to anybody in the next day or two, I'll do a bisection.

Thanks!