all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: juri@linkov.net, federicotedin@gmail.com, 32777@debbugs.gnu.org
Subject: bug#32777: 27.0.50; window-buffer gets wrong point
Date: Sun, 23 Dec 2018 10:40:13 +0100	[thread overview]
Message-ID: <5C1F57FD.2090103@gmx.at> (raw)
In-Reply-To: <83pntuc1g5.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

 > 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

[-- Attachment #2: xdisp.c.diff --]
[-- Type: text/plain, Size: 2251 bytes --]

diff --git a/src/xdisp.c b/src/xdisp.c
index 94742c2..315dce2 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11860,7 +11860,7 @@ static void ATTRIBUTE_FORMAT_PRINTF (1, 0)
   Vmode_line_unwind_vector = Qnil;
 
   if (NILP (vector))
-    vector = make_nil_vector (10);
+    vector = make_nil_vector (12);
 
   ASET (vector, 0, make_fixnum (mode_line_target));
   ASET (vector, 1, make_fixnum (MODE_LINE_NOPROP_LEN (0)));
@@ -11877,12 +11877,24 @@ static void ATTRIBUTE_FORMAT_PRINTF (1, 0)
   ASET (vector, 7, owin);
   if (target_frame)
     {
+      Lisp_Object buffer = XWINDOW (target_frame->selected_window)->contents;
+      struct buffer *b = XBUFFER (buffer);
+      struct buffer *cb = current_buffer;
+
       /* Similarly to `with-selected-window', if the operation selects
 	 a window on another frame, we must restore that frame's
 	 selected window, and (for a tty) the top-frame.  */
       ASET (vector, 8, target_frame->selected_window);
       if (FRAME_TERMCAP_P (target_frame))
 	ASET (vector, 9, FRAME_TTY (target_frame)->top_frame);
+
+      /* If we select a window on another frame, make sure that that
+	 selection does not leave its buffer's point modified when
+	 unwinding (Bug#32777).  */
+      ASET (vector, 10, buffer);
+      current_buffer = b;
+      ASET (vector, 11, build_marker (current_buffer, PT, PT_BYTE));
+      current_buffer = cb;
     }
 
   return vector;
@@ -11913,12 +11925,26 @@ static void ATTRIBUTE_FORMAT_PRINTF (1, 0)
 	{
 	  Lisp_Object frame
 	    = WINDOW_FRAME (XWINDOW (target_frame_window));
+	  Lisp_Object buffer = AREF (vector, 10);
 
 	  if (!EQ (frame, WINDOW_FRAME (XWINDOW (old_window))))
 	    Fselect_window (target_frame_window, Qt);
 
 	  if (!NILP (old_top_frame) && !EQ (old_top_frame, frame))
 	    Fselect_frame (old_top_frame, Qt);
+
+	  if (BUFFER_LIVE_P (XBUFFER (buffer))
+	      && !EQ (XWINDOW (old_window)->contents, buffer))
+	    {
+	      /* Restore point of target_frame_window's buffer
+		 (Bug#32777).  */
+	      struct buffer *cb = current_buffer;
+
+	      current_buffer = XBUFFER (buffer);
+	      set_point_from_marker (AREF (vector, 11));
+	      ASET (vector, 11, Qnil);
+	      current_buffer = cb;
+	    }
 	}
 
       Fselect_window (old_window, Qt);


  reply	other threads:[~2018-12-23  9:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-19 22:55 bug#32777: 27.0.50; window-buffer gets wrong point Juri Linkov
2018-09-30  4:03 ` Federico Tedin
2018-10-02  2:07   ` Federico Tedin
2018-10-02  3:21     ` Eli Zaretskii
2018-10-02 12:31       ` Federico Tedin
2018-10-13  9:19         ` Eli Zaretskii
2018-10-13 13:08           ` martin rudalics
2018-10-15  7:56             ` martin rudalics
2018-12-21  0:18               ` Juri Linkov
2018-12-21  9:15                 ` martin rudalics
2018-12-21 16:02                   ` Eli Zaretskii
2018-12-23  9:40                     ` martin rudalics [this message]
2018-12-29  9:59                       ` martin rudalics
2018-12-29 23:10                         ` Juri Linkov
2018-12-30  9:49                           ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5C1F57FD.2090103@gmx.at \
    --to=rudalics@gmx.at \
    --cc=32777@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=federicotedin@gmail.com \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.