GNU bug report logs - #31695
minibuffer command takes window-point from another frame displaying the same buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31695 in the body.
You can then email your comments to 31695 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: bug-gnu-emacs <at> gnu.org
Subject: bug-gnu-emacs <at> gnu.org
Date: Sun, 03 Jun 2018 10:17:06 +0530 (IST)

The window-point jumps unexpectedly after minibuffer interaction when a
buffer is being displayed in two frames, and the frames do not have
their own minibuffers.

To reproduce: emacs -Q -D and create two frames displaying some buffer
at different points

(with-selected-frame (setq $a (make-frame '((minibuffer))))
  (let ((enable-local-variables :all))
    (view-emacs-news)
    (beginning-of-buffer)))

(with-selected-frame (setq $b (make-frame '((minibuffer))))
  (let ((enable-local-variables :all))
    (view-emacs-news)
    (end-of-buffer)))

Now select frame $b, and execute some minibuffer command:
M-: 1

The point in the window of frame $b, which was at the bottom now jumps
to the top of the buffer.  (This corresponds with the point in the
buffer in the other frame where it is displayed.

In GNU Emacs 27.0.50
Repository revision: d2d35febf28632aafb087952fd4c07c2899e21c5
Windowing system distributor 'The X.Org Foundation', version 11.0.11004000

Configured using:
 'configure -C --without-all --with-xml2 --with-dbus --with-m17n-flt
 --with-libotf --with-xft --without-x-toolkit
 --without-toolkit-scroll-bars'

Configured features:
DBUS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT OLDXMENU X11
[snip]

Message #10 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Madhu <enometh <at> meer.net>, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Sun, 03 Jun 2018 14:21:58 +0200

> The window-point jumps unexpectedly after minibuffer interaction when a
> buffer is being displayed in two frames, and the frames do not have
> their own minibuffers.
>
> To reproduce: emacs -Q -D and create two frames displaying some buffer
> at different points
>
> (with-selected-frame (setq $a (make-frame '((minibuffer))))
>    (let ((enable-local-variables :all))
>      (view-emacs-news)
>      (beginning-of-buffer)))
>
> (with-selected-frame (setq $b (make-frame '((minibuffer))))
>    (let ((enable-local-variables :all))
>      (view-emacs-news)
>      (end-of-buffer)))
>
> Now select frame $b, and execute some minibuffer command:
> M-: 1
>
> The point in the window of frame $b, which was at the bottom now jumps
> to the top of the buffer.  (This corresponds with the point in the
> buffer in the other frame where it is displayed.

This works correctly here in Emacs 23.4.1 and is broken in 24.5.50.1.
If Eli doesn't come up with a clue, could someone with a fast machine
please try to bisect this.

Thanks in advance, martin

Message #13 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Sun, 03 Jun 2018 19:38:23 +0300

> Date: Sun, 03 Jun 2018 14:21:58 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
> This works correctly here in Emacs 23.4.1 and is broken in 24.5.50.1.

It became broken in Emacs 24.3, according to my testing.

> If Eli doesn't come up with a clue, could someone with a fast machine
> please try to bisect this.

Right.

If no one comes up with the culprit, I will look into this tomorrow.

Message #20 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rudalics <at> gmx.at
Cc: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Mon, 04 Jun 2018 19:29:12 +0300

> Date: Sun, 03 Jun 2018 19:38:23 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
> 
> > Date: Sun, 03 Jun 2018 14:21:58 +0200
> > From: martin rudalics <rudalics <at> gmx.at>
> > 
> > This works correctly here in Emacs 23.4.1 and is broken in 24.5.50.1.
> 
> It became broken in Emacs 24.3, according to my testing.
> 
> > If Eli doesn't come up with a clue, could someone with a fast machine
> > please try to bisect this.
> 
> Right.
> 
> If no one comes up with the culprit, I will look into this tomorrow.

I took a look, but as expected, got lost among twisted little
passages, all alike.  It looks like the problem might be with the
insane dance we perform when entering recursive edit in the
minibuffer, where we save and restore the window configuration of the
selected frame, and also of the frame that serves as the minibuffer
frame for the selected frame.  Another potential culprit is
select_window_1, which added the call to set_point_from_marker at its
end, something that wasn't there in Emacs 24.2.

In any case, the immediate cause of the problem is that when redisplay
is entered the offending window is selected and has its point set at
BOB.  So redisplays redraws it accordingly.

Btw, note that if you modify the recipe to do it from frame $a, the
problem doesn't happen.  Which seems to imply that this is somehow
related to the order in which redisplay redraws frames.  I think.

Let me know if I can help more.

Message #23 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Gemini Lasswell <gazally <at> runbox.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Madhu <enometh <at> meer.net>, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Mon, 04 Jun 2018 13:40:30 -0700

martin rudalics <rudalics <at> gmx.at> writes:

> This works correctly here in Emacs 23.4.1 and is broken in 24.5.50.1.
> If Eli doesn't come up with a clue, could someone with a fast machine
> please try to bisect this.

I bisected and got this:

c4b6914d3621942393a3a69d5cee3e39e13c6227 is the first bad commit
commit c4b6914d3621942393a3a69d5cee3e39e13c6227
Author: Martin Rudalics <rudalics <at> gmx.at>
Date:   Mon Aug 27 10:31:19 2012 +0200

    Address two problems in Fset_window_configuration (Bug#8789) and (Bug#12208).
    
    * window.c (Fset_window_configuration): Record any window's old
    buffer if it's replaced (see Bug#8789).  If the new current
    buffer doesn't appear in the selected window, go to its old
    point (Bug#12208).

Message #26 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Tue, 05 Jun 2018 15:36:48 +0200

> I took a look, but as expected, got lost among twisted little
> passages, all alike.  It looks like the problem might be with the
> insane dance we perform when entering recursive edit in the
> minibuffer, where we save and restore the window configuration of the
> selected frame, and also of the frame that serves as the minibuffer
> frame for the selected frame.

This is indeed a very troublesome aspect because we restore the
current buffer (which is per se not related to window configurations)
twice.  Basically, it should suffice to save/restore selected frame
and current buffer around saving/restoring the configuration of the
minibuffer frame, but I'm afraid that this might lead to subtle
changes that would go undetected for another six years.

The real problem is described in this comment

	/* BUF_PT (XBUFFER (new_current_buffer)) gives us the position of
	   point in new_current_buffer as of the last time this buffer was
	   used.  This can be non-deterministic since it can be changed by
	   things like jit-lock by mere temporary selection of some random
	   window that happens to show this buffer.
	   So if possible we want this arbitrary choice of "which point" to
	   be the one from the to-be-selected-window so as to prevent this
	   window's cursor from being copied from another window.  */

and indeed my change which causes the current bug executes

	  old_point = BUF_PT (XBUFFER (new_current_buffer));

and later does

      if (!EQ (XWINDOW (data->current_window)->contents, new_current_buffer))
	Fgoto_char (make_number (old_point));

where old_point is BUF_PT obtained from the other frame showing NEWS -
the one at BOB.  And it does this when restoring the configuration of
the minibuffer frame.  When restoring the NEWS frame the wrong setting
is already cast.  Replacing the last two lines with

      if (!EQ (XWINDOW (selected_window)->contents, new_current_buffer))
	Fgoto_char (make_number (old_point));

fixes both the present bug and the behavior from Bug#12208 so if I do
not find a better solution I intend to use that.  IMHO the idea behind

  new_current_buffer = data->f_current_buffer;

is inherently botched when restoring a frame where that buffer appears
on another frame.

> Another potential culprit is
> select_window_1, which added the call to set_point_from_marker at its
> end, something that wasn't there in Emacs 24.2.

This might be related but I have not found any impact yet.

> In any case, the immediate cause of the problem is that when redisplay
> is entered the offending window is selected and has its point set at
> BOB.  So redisplays redraws it accordingly.
>
> Btw, note that if you modify the recipe to do it from frame $a, the
> problem doesn't happen.  Which seems to imply that this is somehow
> related to the order in which redisplay redraws frames.  I think.

I'm quite sure this is the case.  To make it happen from $a you have
to set the window point of $b first, then in $a choose another window
point and then start the minibuffer rigmarole.

martin

Message #29 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Gemini Lasswell <gazally <at> runbox.com>
Cc: Madhu <enometh <at> meer.net>, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Tue, 05 Jun 2018 15:37:01 +0200

> I bisected and got this:
>
> c4b6914d3621942393a3a69d5cee3e39e13c6227 is the first bad commit
> commit c4b6914d3621942393a3a69d5cee3e39e13c6227
> Author: Martin Rudalics <rudalics <at> gmx.at>
> Date:   Mon Aug 27 10:31:19 2012 +0200
>
>      Address two problems in Fset_window_configuration (Bug#8789) and (Bug#12208).
>
>      * window.c (Fset_window_configuration): Record any window's old
>      buffer if it's replaced (see Bug#8789).  If the new current
>      buffer doesn't appear in the selected window, go to its old
>      point (Bug#12208).

Thank you very much for the work.  I would have spent a couple of
hours doing that here.

martin

Message #34 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Madhu <enometh <at> meer.net>, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Thu, 07 Jun 2018 10:39:13 +0200

> The window-point jumps unexpectedly after minibuffer interaction when a
> buffer is being displayed in two frames, and the frames do not have
> their own minibuffers.
>
> To reproduce: emacs -Q -D and create two frames displaying some buffer
> at different points
>
> (with-selected-frame (setq $a (make-frame '((minibuffer))))
>    (let ((enable-local-variables :all))
>      (view-emacs-news)
>      (beginning-of-buffer)))
>
> (with-selected-frame (setq $b (make-frame '((minibuffer))))
>    (let ((enable-local-variables :all))
>      (view-emacs-news)
>      (end-of-buffer)))
>
> Now select frame $b, and execute some minibuffer command:
> M-: 1
>
> The point in the window of frame $b, which was at the bottom now jumps
> to the top of the buffer.  (This corresponds with the point in the
> buffer in the other frame where it is displayed.

This should be fixed now on the Emacs 26.2 release branch.  The
precise reason of the bug is yet unknown to me but what happens is the
following: When restoring the configuration of the minibuffer-frame
after execution of the minibuffer command, 'set-window-configuration'
assigns

    old_point = BUF_PT (XBUFFER (new_current_buffer));

because new_current_buffer (which is NEWS) is not the current buffer
(which is *Minibuf-1*) and because data->current_window does not show
NEWS.  I can't tell why BUF_PT gets value from the window showing NEWS
at BOB but a comment in 'set-window-configuration' says that this may
happen.

Note that data->current_window shows *scratch* and this is the window
that will become the minibuffer frame's selected window instead of the
minibuffer window.

Now after data->selected_frame (which is the frame showing NEWS at
EOB) has been reselected, 'set-window-configuration' does

      if (!EQ (XWINDOW (data->current_window)->contents, new_current_buffer))
	Fgoto_char (make_number (old_point));

and since data->current_window shows *scratch* (and not NEWS) going to
old_point will cause the point of the window showing NEWS at EOB show
it at BOB instead.

In my fix I use

      if (!EQ (XWINDOW (selected_window)->contents, new_current_buffer))
	Fgoto_char (make_number (old_point));

instead and since selected_window already shows new_current_buffer at
that time the bug should not happen.

If you build from the release branch, please try it.  If you build
from master only, please wait a few days until the change has been
propagated there.

Belated thanks for the simple recipe, martin

Message #37 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Thu, 07 Jun 2018 18:30:18 +0300

> Date: Thu, 07 Jun 2018 10:39:13 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Now select frame $b, and execute some minibuffer command:
>  > M-: 1
>  >
>  > The point in the window of frame $b, which was at the bottom now jumps
>  > to the top of the buffer.  (This corresponds with the point in the
>  > buffer in the other frame where it is displayed.
> 
> This should be fixed now on the Emacs 26.2 release branch.

Are you sure it's a good idea to put this on the emacs-26 branch?
This bug is a mere annoyance, and happens with quite a peculiar frame
configuration that's probably rarely used, judging by the time it took
us to collect only 2 reports about it, since the bug was introduced.
OTOH, we have a somewhat poor record regarding correctness in that
area, so it's quite possible this fix introduces some new issue.

So unless you are really, REALLY sure this should go to emacs-26, I'd
prefer to have it on master, and let the dust settle on it before we
decide it's TRT.

Thanks for working on this and for finding a fix.

> Belated thanks for the simple recipe, martin

Seconded.

Message #40 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Fri, 08 Jun 2018 10:00:42 +0200

> Are you sure it's a good idea to put this on the emacs-26 branch?

Yes.  As you can see from the comment back then

      /* If the new current buffer doesn't appear in the selected
	 window, go to its old point (see bug#12208).  */
      if (!EQ (XWINDOW (data->current_window)->contents, new_current_buffer))

that fix was based on the wrong assumption that data->current_window
_is_ the selected window.  It is not when data->current_window is not
on the selected frame.  That was a thinko and the fix on Emacs 26
corrects it.

> This bug is a mere annoyance, and happens with quite a peculiar frame
> configuration that's probably rarely used, judging by the time it took
> us to collect only 2 reports about it, since the bug was introduced.
> OTOH, we have a somewhat poor record regarding correctness in that
> area, so it's quite possible this fix introduces some new issue.

Maybe we didn't get more reports because some people thought that the
"annoyance" is the expected behavior.  Even the OP was "hesitant" to
file the report.

> So unless you are really, REALLY sure this should go to emacs-26, I'd
> prefer to have it on master, and let the dust settle on it before we
> decide it's TRT.

The only justifiable alternative I see is to revert the fix for
Bug#12208 on Emacs 26 since that bug is even more obscure than the
present one.

But whatever you decide the responsibility will be all mine.

martin

Message #43 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Fri, 08 Jun 2018 11:18:14 +0300

> Date: Fri, 08 Jun 2018 10:00:42 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
> 
>  > So unless you are really, REALLY sure this should go to emacs-26, I'd
>  > prefer to have it on master, and let the dust settle on it before we
>  > decide it's TRT.
> 
> The only justifiable alternative I see is to revert the fix for
> Bug#12208 on Emacs 26 since that bug is even more obscure than the
> present one.

I see no reason to revert the fix for 12208, so emacs-26 it is.
Thanks.

> But whatever you decide the responsibility will be all mine.

That's not what I was worried about ;-)

Message #46 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, martin rudalics <rudalics <at> gmx.at>
Cc: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
Subject: RE: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Fri, 8 Jun 2018 06:58:39 -0700 (PDT)

Could this bug title please be changed to reflect what
the bug is about?  Perhaps return to a title similar
to the other bug(s) that were merged with this one?

Message #49 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: rudalics <at> gmx.at, enometh <at> meer.net, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Fri, 08 Jun 2018 17:36:17 +0300

> Date: Fri, 8 Jun 2018 06:58:39 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: enometh <at> meer.net, 31695 <at> debbugs.gnu.org
> 
> Could this bug title please be changed to reflect what
> the bug is about?  Perhaps return to a title similar
> to the other bug(s) that were merged with this one?

The bug report didn't lose its title, it's just that email messages
did.

Message #52 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 31695 <at> debbugs.gnu.org, enometh <at> meer.net
Subject: Re: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Fri, 08 Jun 2018 16:38:15 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> Could this bug title please be changed to reflect what
> the bug is about?  Perhaps return to a title similar
> to the other bug(s) that were merged with this one?

Noam retitled it on Sunday

Robert

Message #55 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: rudalics <at> gmx.at, enometh <at> meer.net, 31695 <at> debbugs.gnu.org
Subject: RE: bug#31695: bug-gnu-emacs <at> gnu.org
Date: Fri, 8 Jun 2018 07:47:18 -0700 (PDT)

> > Could this bug title please be changed to reflect what
> > the bug is about?  Perhaps return to a title similar
> > to the other bug(s) that were merged with this one?
> 
> The bug report didn't lose its title, it's just that email messages
> did.

I see.  Could the email Subject please be changed, in that case?

Message #58 received at 31695 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Madhu <enometh <at> meer.net>, 31695 <at> debbugs.gnu.org
Subject: Re: bug#31695: minibuffer command takes window-point from another
 frame displaying the same buffer
Date: Wed, 13 Jun 2018 23:32:53 -0400

tags 31695 fixed
close 31695 26.2
quit

martin rudalics <rudalics <at> gmx.at> writes:

> This should be fixed now on the Emacs 26.2 release branch.

Works for me.

[1: 26b52ac40e]: 2018-06-07 09:59:38 +0200
  Fix unexpected jumps of window-point in 'set-window-configuration' (Bug#31695)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=26b52ac40e78cb7ac3df3bf87e514ad137f0ce10

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.