all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#48249: 28.0.50; Regression: emacs confused about window configuration due to ido-mode and/or winner-mode
@ 2021-05-06  3:50 Dima Kogan
  2021-05-06  7:30 ` Gregory Heytings
  2021-05-06 12:30 ` Basil L. Contovounesios
  0 siblings, 2 replies; 22+ messages in thread
From: Dima Kogan @ 2021-05-06  3:50 UTC (permalink / raw)
  To: 48249

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!





^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2021-05-08 12:30 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-05-06  3:50 bug#48249: 28.0.50; Regression: emacs confused about window configuration due to ido-mode and/or winner-mode Dima Kogan
2021-05-06  7:30 ` Gregory Heytings
2021-05-06  8:04   ` Eli Zaretskii
2021-05-06  8:17     ` Gregory Heytings
2021-05-06  9:39       ` Eli Zaretskii
2021-05-06  9:57         ` Gregory Heytings
2021-05-06 10:15           ` Eli Zaretskii
2021-05-06 11:48             ` Gregory Heytings
2021-05-06 12:30 ` Basil L. Contovounesios
2021-05-06 12:39   ` Gregory Heytings
2021-05-06 13:25     ` Basil L. Contovounesios
2021-05-06 13:38       ` Gregory Heytings
2021-05-06 13:58         ` Gregory Heytings
2021-05-06 14:22         ` Basil L. Contovounesios
2021-05-06 14:49     ` Basil L. Contovounesios
2021-05-06 19:25   ` Alan Mackenzie
2021-05-07  9:49   ` Alan Mackenzie
2021-05-07 10:24     ` Basil L. Contovounesios
2021-05-07 12:02     ` Gregory Heytings
2021-05-07 12:43       ` Alan Mackenzie
2021-05-07 20:30     ` Dima Kogan
2021-05-08 12:30       ` Alan Mackenzie

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.