GNU bug report logs - #32777
27.0.50; window-buffer gets wrong point

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32777 <at> debbugs.gnu.org, federicotedin <at> gmail.com, juri <at> linkov.net
Subject: Re: bug#32777: 27.0.50; window-buffer gets wrong point
Date: Sun, 23 Dec 2018 10:40:13 +0100

[Message part 1 (text/plain, inline)]

> As for how to proceed: I would love for us to have a way of selecting
> a window temporarily, in way that doesn't involve saving/restoring its
> window-point.

It depends on what your semantics of "selecting a window temporarily"
are.  The only invariance frame/window management requires is that
(frame-selected-window (selected-frame)) equals (selected-window).
Otherwise you can freely set things like selected_window and
selected_frame directly.

Things get problematic when you want to, for example, show the line
number of a buffer in the mode line since in that case you need the
corresponding window's point which is stored in the window structure
only if the window is not the selected one.  So the most important
prerequisite for what you want is that redisplay itself always has a
very strong opinion of which window is the selected one and which
buffer is current.

One of the most unexpected things redisplay currently does is to run
Fselect_frame from unwind_format_mode_line which if I'm not mistaken
could wind up calling do_switch_frame with TRACK non-zero and thus
cause a Fredirect_frame_focus from within redisplay.  I think that
redisplay should not call 'select-frame' or 'select-window' for such
reasons.

> But maybe this is a pipe dream, so I think we should
> try your alternative #2 on master and see what it breaks.

To elaborate further on what I stated there as

>> But (1) does not handle the case where the
>> buffer of W2 is not shown anywhere else when x_consider_frame_title is
>> called.  So IMHO (2) should be the correct approach but I have no idea
>> what further consequences it could have.

consider the following scenario with emacs -Q:

C-x 5 2

C-x 5 o

C-x b RET

M-: (with-current-buffer "*scratch*" (goto-char (point-min)))

M-: (with-current-buffer "*scratch*" (point))

The value of evaluating the second form depends on the position of
point of the window displaying *scratch* and not on where the
'goto-char' went before.  So this is a quite nasty bug IMHO.

Unfortunately, curing it is non-trivial to avoid that some window
point gets moved unexpectedly, see the attached patch.  People using
multiple frames pretty please try to run it and report any bad
experiences here ASAP.

Thanks, martin

[xdisp.c.diff (text/plain, attachment)]

Previous Next

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