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

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!

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

[Gregory Heytings]

>
> 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.
>
> 1. emacs -Q --eval "(progn (ido-mode 'buffers) (winner-mode))"
> 2. C-x b RET
> 3. C-c LEFT
> 4. M-x
> 5. C-g
>

Thanks for your bug report.

The bug of this specific recipe is due to commit 7c2ebf6e23.

I wonder how many more bug reports are needed before the lesson of that 
failed experiment will finally be drawn.

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

[Eli Zaretskii]

> Date: Thu, 06 May 2021 07:30:29 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: 48249@debbugs.gnu.org
> 
> I wonder how many more bug reports are needed before the lesson of that 
> failed experiment will finally be drawn.

Significant changes in low-level infrastructure frequently cause a
trail of unintended consequences that need to be fixed.  The fact that
these consequences exist doesn't yet mean the change is a "failed
experiment", so please don't be too eager to reach that conclusion
based on just having bug reports such as this one.  If you think what
we saw till now as result of that changeset is a catastrophe, you just
didn't see enough serious low-level changes in Emacs yet.

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

[Gregory Heytings]

>> I wonder how many more bug reports are needed before the lesson of that 
>> failed experiment will finally be drawn.
>
> Significant changes in low-level infrastructure frequently cause a trail 
> of unintended consequences that need to be fixed.
>

When a low-level infrastructure has worked flawlessly for more than a 
decade, making significant changes in it without making them conditional 
to a run-time variable or a compilation option, until the new code is 
"proven" enough, is unwise.  That's what happened with native compilation 
for example, or with Cairo, or...  And this is all I asked when this 
experiment started.

>
> If you think what we saw till now as result of that changeset is a 
> catastrophe, you just didn't see enough serious low-level changes in 
> Emacs yet.
>

Did other low-level changes in Emacs result in segfaults and several bug 
reports of confused users each week?  I'd hope not.

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

[Eli Zaretskii]

> Date: Thu, 06 May 2021 08:17:59 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 48249@debbugs.gnu.org, dima@secretsauce.net
> 
> > Significant changes in low-level infrastructure frequently cause a trail 
> > of unintended consequences that need to be fixed.
> 
> When a low-level infrastructure has worked flawlessly for more than a 
> decade, making significant changes in it without making them conditional 
> to a run-time variable or a compilation option, until the new code is 
> "proven" enough, is unwise.

First, a knob to control new code is not always possible, though I
agree it is preferable when it's feasible.  In this case, we do have a
knob to control the new code, albeit not a knob that goes back to the
previous behavior with 100% accuracy.  It's possible that the OP
should try flipping that option, maybe it will work around the problem
(not that I think it's necessarily the solution).

More generally, that's development for you; without risking such
destabilization from time to time we can never afford significant
improvements.  The important question is: will the new-and-improved
behavior be useful or won't it?

> > If you think what we saw till now as result of that changeset is a 
> > catastrophe, you just didn't see enough serious low-level changes in 
> > Emacs yet.
> 
> Did other low-level changes in Emacs result in segfaults and several bug 
> reports of confused users each week?  I'd hope not.

Yes, of course.  The introduction of bidirectional editing support
during development of Emacs 24.1 comes to mind.  Like I said: stick
around some more, and you will see more examples.

Emacs 28.1 is still many moons away.  We will figure this out till
then, don't worry.

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

[Gregory Heytings]

>> When a low-level infrastructure has worked flawlessly for more than a 
>> decade, making significant changes in it without making them 
>> conditional to a run-time variable or a compilation option, until the 
>> new code is "proven" enough, is unwise.
>
> First, a knob to control new code is not always possible, though I agree 
> it is preferable when it's feasible.
>

It is _always_ possible.  Whether through conditional compilation or 
through conditional code.

>
> In this case, we do have a knob to control the new code, albeit not a 
> knob that goes back to the previous behavior with 100% accuracy.  It's 
> possible that the OP should try flipping that option, maybe it will work 
> around the problem (not that I think it's necessarily the solution).
>

Turning the knob doesn't work here, the bug occurs regardless of the value 
of that knob.  Otherwise I would have mentioned that in my reply to Dima.

>
> More generally, that's development for you; without risking such 
> destabilization from time to time we can never afford significant 
> improvements. The important question is: will the new-and-improved 
> behavior be useful or won't it?
>

Indeed perhaps the most important question here is: is this a "significant 
improvement"?  IMO, the answer is clearly "no".  Will this new behavior be 
"useful"?  In this case I'd say "perhaps, for very few users, even though 
nobody requested it".  But a marginal improvement that will benefit a few 
users is not worth taking the risk of unconditionally destabilizing old, 
time-proved code.

>
> Yes, of course.  The introduction of bidirectional editing support 
> during development of Emacs 24.1 comes to mind.
>

That was, of course, a significant improvement that was worth taking the 
risk of destabilization.

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

[Eli Zaretskii]

> Date: Thu, 06 May 2021 09:57:04 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 48249@debbugs.gnu.org, dima@secretsauce.net
> 
> > More generally, that's development for you; without risking such 
> > destabilization from time to time we can never afford significant 
> > improvements. The important question is: will the new-and-improved 
> > behavior be useful or won't it?
> 
> Indeed perhaps the most important question here is: is this a "significant 
> improvement"?  IMO, the answer is clearly "no".

I know, and I think that opinion makes your judgment of the results
too severe.

> > Yes, of course.  The introduction of bidirectional editing support 
> > during development of Emacs 24.1 comes to mind.
> 
> That was, of course, a significant improvement that was worth taking the 
> risk of destabilization.

I wish you were here when that was introduced and heard some of the
opinions voiced back then (and still being voiced from time to time).

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

[Gregory Heytings]

>>> More generally, that's development for you; without risking such 
>>> destabilization from time to time we can never afford significant 
>>> improvements. The important question is: will the new-and-improved 
>>> behavior be useful or won't it?
>>
>> Indeed perhaps the most important question here is: is this a 
>> "significant improvement"?  IMO, the answer is clearly "no".
>
> I know, and I think that opinion makes your judgment of the results too 
> severe.
>

That's possible, indeed.  But so far I haven't seen a single concrete 
example that demonstrates that this feature is either (a) necessary in 
some circumstances (as was bidirectional editing support), or (b) not 
necessary but at least useful in some circumstances.

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

[Basil L. Contovounesios]

Dima Kogan <dima@secretsauce.net> writes:

> 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.

Exactly the same story here with ivy-mode and winner-mode.  I thought
I'd found a reproducer in https://bugs.gnu.org/48229, but that's
actually a duplicate of https://bugs.gnu.org/47766, which was fixed
today:

Fix wrong handling of minibuffers when frames get iconified/made invisible
c873d16af6 2021-05-06 10:48:14 +0000
https://git.sv.gnu.org/cgit/emacs.git/commit/?id=c873d16af61ae9b956c6dd6d9e50ebad2bb7666e

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

I can confirm the bug in your recipe still happens with latest master
(report-emacs-bug details follow my signature).  CCing Alan.

Thanks,

-- 
Basil

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-05-06 built on tia
Repository revision: 5ec4a3dbbc81ef9ed51065189a19689c351e0e8d
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux bullseye/sid

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Winner undo (1 / 2)
Quit

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --enable-checking=structs
 --with-x-toolkit=lucid --with-file-notification=yes --with-x'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_IE.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: InactiveMinibuffer

Minor modes in effect:
  winner-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils winner ring ido seq byte-opt gv
bytecomp byte-compile cconv iso-transl tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 55722 8253)
 (symbols 48 6957 1)
 (strings 32 19914 1941)
 (string-bytes 1 653549)
 (vectors 16 13237)
 (vector-slots 8 177049 10255)
 (floats 8 34 50)
 (intervals 56 232 0)
 (buffers 992 10))

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

[Gregory Heytings]

[For some reason my emails to Basil are rejected by Outlook ("host 
tcd-ie.mail.protection.outlook.com[104.47.4.36] said: 550 5.7.606 Access 
denied"), so I send this mail to the bugtracker instead, hoping that he'll 
get them.]

>
> I can confirm the bug in your recipe still happens with latest master 
> (report-emacs-bug details follow my signature).
>

As I said a few hours ago: could you try to revert 7c2ebf6e23 locally and 
see if the issue persists?

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

[Basil L. Contovounesios]

Gregory Heytings <gregory@heytings.org> writes:

> [For some reason my emails to Basil are rejected by Outlook ("host
> tcd-ie.mail.protection.outlook.com[104.47.4.36] said: 550 5.7.606 Access
> denied"), so I send this mail to the bugtracker instead, hoping that he'll get
> them.]

Were those emails on- or off-list?  Because I received this message of
yours: https://bugs.gnu.org/48229#11.

FWIW, my university email is hosted by Gmail.  I'll send you the
relevant email headers I'm seeing off-list.

>> I can confirm the bug in your recipe still happens with latest master
>> (report-emacs-bug details follow my signature).
>
> As I said a few hours ago: could you try to revert 7c2ebf6e23 locally and see if
> the issue persists?

I can't revert the commit cleanly, but I can reproduce Dima's recipe on
that revision and not on its parent.

Thanks,

-- 
Basil

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

[Gregory Heytings]

>> [For some reason my emails to Basil are rejected by Outlook ("host 
>> tcd-ie.mail.protection.outlook.com[104.47.4.36] said: 550 5.7.606 
>> Access denied"), so I send this mail to the bugtracker instead, hoping 
>> that he'll get them.]
>
> Were those emails on- or off-list?  Because I received this message of 
> yours: https://bugs.gnu.org/48229#11.
>

Yes, that was on-list, and you received it through the list, not directly 
from me.

>
> FWIW, my university email is hosted by Gmail.  I'll send you the 
> relevant email headers I'm seeing off-list.
>

Not by Gmail, by Microsoft (Outlook):

$ dig +short -t mx tcd.ie
10 tcd-ie.mail.protection.outlook.com.

Whenever you're in the recipient list I receive a "host 
tcd-ie.mail.protection.outlook.com[104.47.4.36] said: 550 5.7.606 Access 
denied" error message.  I'm the one who can do something about it, not 
you, but removing oneself from Outlook's blocklists is a painful process.

>> As I said a few hours ago: could you try to revert 7c2ebf6e23 locally 
>> and see if the issue persists?
>
> I can't revert the commit cleanly, but I can reproduce Dima's recipe on 
> that revision and not on its parent.
>

Indeed, but what about your recipe (bug#48229)?

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

[Gregory Heytings]

[For Basil:] Thanks for your private email, I cannot reply to it (all my 
emails are rejected), and alas you cannot do anything to resolve this :(

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

[Basil L. Contovounesios]

Gregory Heytings <gregory@heytings.org> writes:

>>> [For some reason my emails to Basil are rejected by Outlook ("host
>>> tcd-ie.mail.protection.outlook.com[104.47.4.36] said: 550 5.7.606 Access
>>> denied"), so I send this mail to the bugtracker instead, hoping that he'll
>>> get them.]
>>
>> FWIW, my university email is hosted by Gmail.  I'll send you the relevant
>> email headers I'm seeing off-list.
>
> Not by Gmail, by Microsoft (Outlook):

No, it's hosted by Gmail.  Clearly they also use Outlook behind the
scenes.

> $ dig +short -t mx tcd.ie
> 10 tcd-ie.mail.protection.outlook.com.
>
> Whenever you're in the recipient list I receive a "host
> tcd-ie.mail.protection.outlook.com[104.47.4.36] said: 550 5.7.606 Access denied"
> error message.  I'm the one who can do something about it, not you, but removing
> oneself from Outlook's blocklists is a painful process.

Godspeed.

>>> As I said a few hours ago: could you try to revert 7c2ebf6e23 locally and see
>>> if the issue persists?
>>
>> I can't revert the commit cleanly, but I can reproduce Dima's recipe on that
>> revision and not on its parent.
>
> Indeed, but what about your recipe (bug#48229)?

Same story, but as I said upthread that recipe is a duplicate of
bug#47766, which was fixed today.

Thanks,

-- 
Basil

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

[Basil L. Contovounesios]

Gregory Heytings <gregory@heytings.org> writes:

> [For some reason my emails to Basil are rejected by Outlook ("host
> tcd-ie.mail.protection.outlook.com[104.47.4.36] said: 550 5.7.606 Access
> denied"), so I send this mail to the bugtracker instead, hoping that he'll get
> them.]

FTR if this happens to anyone else, you can avoid running into Outlook
by sending to blc@member.fsf.org instead (it's ultimately forwarded to
the same address).

I hope that concludes this off-topic tangent; sorry about the noise.

-- 
Basil

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

[Alan Mackenzie]

Hello, Dima and Basil.

Thanks for the bug report about minibuffers.  I can confirm I'm looking
at it now.  Hopefully, it will be resolved soon.

-- 
Alan Mackenzie (Nuremberg, Germany).


On Thu, May 06, 2021 at 13:30:46 +0100, Basil L. Contovounesios wrote:
> Dima Kogan <dima@secretsauce.net> writes:

> > 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.

> Exactly the same story here with ivy-mode and winner-mode.  I thought
> I'd found a reproducer in https://bugs.gnu.org/48229, but that's
> actually a duplicate of https://bugs.gnu.org/47766, which was fixed
> today:

> Fix wrong handling of minibuffers when frames get iconified/made invisible
> c873d16af6 2021-05-06 10:48:14 +0000
> https://git.sv.gnu.org/cgit/emacs.git/commit/?id=c873d16af61ae9b956c6dd6d9e50ebad2bb7666e

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

> I can confirm the bug in your recipe still happens with latest master
> (report-emacs-bug details follow my signature).  CCing Alan.

> Thanks,

> -- 
> Basil

> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
>  of 2021-05-06 built on tia
> Repository revision: 5ec4a3dbbc81ef9ed51065189a19689c351e0e8d
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
> System Description: Debian GNU/Linux bullseye/sid

[ .... ]

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

[Alan Mackenzie]

Hello, Dima and Basil.

On Thu, May 06, 2021 at 13:30:46 +0100, Basil L. Contovounesios wrote:
> Dima Kogan <dima@secretsauce.net> writes:

> > 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.

> Exactly the same story here with ivy-mode and winner-mode.  I thought
> I'd found a reproducer in https://bugs.gnu.org/48229, but that's
> actually a duplicate of https://bugs.gnu.org/47766, which was fixed
> today:

> Fix wrong handling of minibuffers when frames get iconified/made invisible
> c873d16af6 2021-05-06 10:48:14 +0000
> https://git.sv.gnu.org/cgit/emacs.git/commit/?id=c873d16af61ae9b956c6dd6d9e50ebad2bb7666e

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

> I can confirm the bug in your recipe still happens with latest master
> (report-emacs-bug details follow my signature).  CCing Alan.

OK, could you both please try out the following patch.  Forgive me for
not explaining the mechanism of the bug here, it is somewhat involved.
I'm not happy about the internal mechanisms which went wrong, and I
might try later to make these more robust.



diff --git a/lisp/winner.el b/lisp/winner.el
index f30fa6cf5c..a60ef44662 100644
--- a/lisp/winner.el
+++ b/lisp/winner.el
@@ -212,7 +212,7 @@ winner-set-conf
          (minisize (window-height miniwin)))
     (cl-letf (((window-buffer miniwin))
               ((window-point  miniwin)))
-      (set-window-configuration winconf))
+      (set-window-configuration winconf nil t))
     (cond
      ((window-live-p chosen) (select-window chosen))
      ((window-minibuffer-p) (other-window 1)))


> Thanks,

> -- 
> Basil

> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
>  of 2021-05-06 built on tia
> Repository revision: 5ec4a3dbbc81ef9ed51065189a19689c351e0e8d
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
> System Description: Debian GNU/Linux bullseye/sid

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Basil L. Contovounesios]

Alan Mackenzie <acm@muc.de> writes:

> OK, could you both please try out the following patch.

Thanks, with it I can no longer reproduce Dima's recipe, but I'm also
not a heavy user of winner-mode.

> Forgive me for not explaining the mechanism of the bug here, it is
> somewhat involved.  I'm not happy about the internal mechanisms which
> went wrong, and I might try later to make these more robust.

I look forward to it, thanks,

-- 
Basil

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

[Gregory Heytings]

>
> diff --git a/lisp/winner.el b/lisp/winner.el
> index f30fa6cf5c..a60ef44662 100644
> --- a/lisp/winner.el
> +++ b/lisp/winner.el
> @@ -212,7 +212,7 @@ winner-set-conf
>          (minisize (window-height miniwin)))
>     (cl-letf (((window-buffer miniwin))
>               ((window-point  miniwin)))
> -      (set-window-configuration winconf))
> +      (set-window-configuration winconf nil t))
>     (cond
>      ((window-live-p chosen) (select-window chosen))
>      ((window-minibuffer-p) (other-window 1)))
>

This cannot be the right way to fix the bug.  That line was last changed 
more than 20 years ago (commit 2a92dc2540 by RMS).

Or does that mean that from now on each occurrence of 
'set-window-configuration' (there are 98 occurrences in the Emacs core 
only) should take an additional dont-set-miniwindow t argument to avoid 
that bug?

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

[Alan Mackenzie]

Hello, Gregory.

On Fri, May 07, 2021 at 12:02:14 +0000, Gregory Heytings wrote:

> >
> > diff --git a/lisp/winner.el b/lisp/winner.el
> > index f30fa6cf5c..a60ef44662 100644
> > --- a/lisp/winner.el
> > +++ b/lisp/winner.el
> > @@ -212,7 +212,7 @@ winner-set-conf
> >          (minisize (window-height miniwin)))
> >     (cl-letf (((window-buffer miniwin))
> >               ((window-point  miniwin)))
> > -      (set-window-configuration winconf))
> > +      (set-window-configuration winconf nil t))
> >     (cond
> >      ((window-live-p chosen) (select-window chosen))
> >      ((window-minibuffer-p) (other-window 1)))
> >

> This cannot be the right way to fix the bug.  That line was last changed 
> more than 20 years ago (commit 2a92dc2540 by RMS).

I agree it isn't the best way to fix the bug, because that fix isn't
robust enough.  But it's hopefully good enough to relieve the irritation
of the original poster for a short while, while I work on something
better.  It's also good enough to check whether the cause of the bug has
actually been found.  That the source line was last changed so long ago
is neither here nor there.

> Or does that mean that from now on each occurrence of 
> 'set-window-configuration' (there are 98 occurrences in the Emacs core 
> only) should take an additional dont-set-miniwindow t argument to avoid 
> that bug?

That is the problem.  Some of these calls might need the extra argument,
most of them won't.  Such a requirement would be a poor abstraction,
since the typical caller of set-window-configuration shouldn't have to
worry about such details.

By the way, thanks for the service you're providing of identifying bugs
connected with the recent minibuffer changes.  It's appreciated!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dima Kogan]

Thanks for the patch, Alan. Initial testing confirms that the issue is
resolved. I'll dogfood this for a bit to see if anything else comes up.
I don't know if you have any more work planned in this area, so you
should close this bug, if you think this is done.

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

[Alan Mackenzie]

Hello, Dima.

On Fri, May 07, 2021 at 13:30:51 -0700, Dima Kogan wrote:
> Thanks for the patch, Alan. Initial testing confirms that the issue is
> resolved.

Thanks indeed for the testing.

> I'll dogfood this for a bit to see if anything else comes up.  I don't
> know if you have any more work planned in this area, so you should
> close this bug, if you think this is done.

There was another circumstance in which point got left in a dead
mini-window, which I've fixed too.

I've committed a different patch to the master branch from the one I
suggested yesterday, but it addresses the same symptoms in a more robust
fashion.  So, please undo yesterday's patch from your Emacs before
updating to today's version.

I am indeed closing the bug with this post, since I am convinced it is
fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).