unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Juri Linkov <juri@linkov.net>
Cc: 32672@debbugs.gnu.org
Subject: bug#32672: 27.0.50; image resize on window resizing
Date: Wed, 19 Sep 2018 10:22:59 +0200	[thread overview]
Message-ID: <5BA20763.8070305@gmx.at> (raw)
In-Reply-To: <877ejjzr9s.fsf@mail.linkov.net>

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

 > Please try with more buffers than initial 2 (*scratch* and *Messages*),
 > e.g. with *info* (just `C-h i'), I get
 >
 > 1 ... current: *scratch* ... window-buffer: *scratch*

... which is something you probably don't even want - it comes from
'get-buffer-create' when making the *info* buffer ...

 > 2 ... current: *scratch* ... window-buffer: *info*
 >
 > which is in an inconsistent state,

... not really - look at the backtrace:

   foo()
   run-hooks(buffer-list-update-hook)
   record-window-buffer(#<window 3 on *info*>)
   set-window-buffer(#<window 3 on *info*> #<buffer *info*>)
   window--display-buffer(#<buffer *info*> #<window 3 on *info*> reuse ((inhibit-same-window)))
   display-buffer-same-window(#<buffer *info*> ((inhibit-same-window)))
   display-buffer(#<buffer *info*> (display-buffer-same-window (inhibit-same-window)))
   pop-to-buffer("*info*" (display-buffer-same-window (inhibit-same-window)) nil)
   pop-to-buffer-same-window("*info*")
   info(nil nil)
   funcall-interactively(info nil nil)
   call-interactively(info nil nil)
   command-execute(info)

'pop-to-buffer' can "reasonably" select the window and thus implicitly
make its buffer current only _after_ the buffer has been displayed via
'display-buffer-same-window'.  I say reasonably because we could make
the buffer current earlier but this doesn't strike me as a very good
idea.  It would constitute an incompatible change in the internal
behavior of 'pop-to-buffer'.

 > and after typing `q' the hook is called 3 times
 >
 > 3 ... current: *scratch* ... window-buffer: *scratch*
 > 4 ... current: *scratch* ... window-buffer: *scratch*
 > 5 ... current: *scratch* ... window-buffer: *scratch*

Look at the backtraces:

3 ... current: *scratch* ... window-buffer: *scratch*
   run-hooks(buffer-list-update-hook)
   record-window-buffer(#<window 3 on *scratch*>)
   set-window-buffer(#<window 3 on *scratch*> #<buffer *scratch*>)
   set-window-buffer-start-and-point(#<window 3 on *scratch*> #<buffer *scratch*> 1 #<marker at 1598 in *scratch*>)
   quit-restore-window(nil bury)
   quit-window()
   Info-exit()
   funcall-interactively(Info-exit)
   call-interactively(Info-exit nil nil)
   command-execute(Info-exit)

This one comes from replacing the *info* buffer with *scratch* in the
window.

4 ... current: *scratch* ... window-buffer: *scratch*
   run-hooks(buffer-list-update-hook)
   select-window(#<window 3 on *scratch*>)
   quit-restore-window(nil bury)
   quit-window()
   Info-exit()
   funcall-interactively(Info-exit)
   call-interactively(Info-exit nil nil)
   command-execute(Info-exit)

This one comes from selecting that window.

5 ... current: *scratch* ... window-buffer: *scratch*
   run-hooks(buffer-list-update-hook)
   bury-buffer-internal(#<buffer *info*>)
   quit-restore-window(nil bury)
   quit-window()
   Info-exit()
   funcall-interactively(Info-exit)
   call-interactively(Info-exit nil nil)
   command-execute(Info-exit)

And this one comes from burying the *info* buffer.  What should we do
instead?

 > And there is the workflow how to break the correct order
 > of `C-x <right> C-x <left>':
 >
 > 1. Create *info* buffer: `C-h i' and quit `q'
 > 2. Split windows `C-x 2' or `C-x 3' (both windows display *scratch*)
 > 3. Check that `C-x <right> C-x <left>' correctly returns to the original
 >     buffer *scratch* in the first window.
 > 4. After `C-x o' in another window `C-x <right> C-x <left>'
 >     doesn't return to the original buffer *scratch*.
 >     It displays *info*.

Evidently, this comment for 'record-window-buffer'

;; The following function is called by `set-window-buffer' _before_ it
;; replaces the buffer of the argument window with the new buffer.

had its purpose.  Please try the attached patch.

Thanks, martin

[-- Attachment #2: buffer-list-update-hook.diff --]
[-- Type: text/plain, Size: 3585 bytes --]

--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4274,9 +4274,7 @@ record-window-buffer
 			       ;; (Bug#12588).
 			       point window-point-insertion-type)))))
 	  (set-window-prev-buffers
-	   window (cons entry (window-prev-buffers window)))))
-
-      (run-hooks 'buffer-list-update-hook))))
+	   window (cons entry (window-prev-buffers window))))))))
 
 (defun unrecord-window-buffer (&optional window buffer)
   "Unrecord BUFFER in WINDOW.
@@ -4301,9 +4299,9 @@ set-window-buffer-start-and-point
   (setq window (window-normalize-window window t))
   (let ((selected (eq window (selected-window)))
 	(current (eq (window-buffer window) (current-buffer))))
-    (set-window-buffer window buffer)
     (when (and selected current)
       (set-buffer buffer))
+    (set-window-buffer window buffer)
     (when start
       ;; Don't force window-start here (even if POINT is nil).
       (set-window-start window start t))
diff --git a/src/window.c b/src/window.c
index 409b01f..d765564 100644
--- a/src/window.c
+++ b/src/window.c
@@ -3573,40 +3573,38 @@ depends on the value of (window-start WINDOW), so if calling this
 
 This function runs `window-scroll-functions' before running
 `window-configuration-change-hook'.  */)
-  (register Lisp_Object window, Lisp_Object buffer_or_name, Lisp_Object keep_margins)
+     (Lisp_Object window, Lisp_Object buffer_or_name, Lisp_Object keep_margins)
 {
-  register Lisp_Object tem, buffer;
-  register struct window *w = decode_live_window (window);
+  Lisp_Object old_buffer, new_buffer;
+  struct window *w = decode_live_window (window);
 
   XSETWINDOW (window, w);
-  buffer = Fget_buffer (buffer_or_name);
-  CHECK_BUFFER (buffer);
-  if (!BUFFER_LIVE_P (XBUFFER (buffer)))
+  old_buffer = w->contents;
+  new_buffer = Fget_buffer (buffer_or_name);
+  CHECK_BUFFER (new_buffer);
+  if (!BUFFER_LIVE_P (XBUFFER (new_buffer)))
     error ("Attempt to display deleted buffer");
 
-  tem = w->contents;
-  if (NILP (tem))
-    error ("Window is deleted");
-  else
+  if (!EQ (old_buffer, new_buffer))
     {
-      if (!EQ (tem, buffer))
-	{
-	  if (EQ (w->dedicated, Qt))
-	    /* WINDOW is strongly dedicated to its buffer, signal an
-	       error.  */
-	    error ("Window is dedicated to `%s'", SDATA (BVAR (XBUFFER (tem), name)));
-	  else
-	    /* WINDOW is weakly dedicated to its buffer, reset
-	       dedication.  */
-	    wset_dedicated (w, Qnil);
-
-	  call1 (Qrecord_window_buffer, window);
-	}
+      if (EQ (w->dedicated, Qt))
+	/* WINDOW is strongly dedicated to its buffer, signal an
+	   error.  */
+	error ("Window is dedicated to `%s'", SDATA (BVAR (XBUFFER (old_buffer), name)));
+      else
+	/* WINDOW is weakly dedicated to its buffer, reset
+	   dedication.  */
+	wset_dedicated (w, Qnil);
 
-      unshow_buffer (w);
+      call1 (Qrecord_window_buffer, window);
     }
 
-  set_window_buffer (window, buffer, true, !NILP (keep_margins));
+  unshow_buffer (w);
+
+  set_window_buffer (window, new_buffer, true, !NILP (keep_margins));
+
+  if (!NILP (Vrun_hooks) && !EQ (old_buffer, new_buffer))
+    call1 (Vrun_hooks, Qbuffer_list_update_hook);
 
   return Qnil;
 }
@@ -6415,7 +6413,12 @@ struct saved_window
 	      && BUFFER_LIVE_P (XBUFFER (p->buffer)))
 	    /* If a window we restore gets another buffer, record the
 	       window's old buffer.  */
-	    call1 (Qrecord_window_buffer, window);
+	    {
+	      call1 (Qrecord_window_buffer, window);
+
+	      if (!NILP (Vrun_hooks))
+		call1 (Vrun_hooks, Qbuffer_list_update_hook);
+	    }
 	}
 
       /* Disallow x_set_window_size, temporarily.  */


  reply	other threads:[~2018-09-19  8:22 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-09 15:54 bug#32672: 27.0.50; image resize on window resizing Juri Linkov
2018-09-11 23:53 ` Juri Linkov
2018-09-12  6:33   ` martin rudalics
2018-09-12 23:18     ` Juri Linkov
2018-09-13  7:46       ` martin rudalics
2018-09-13 23:20         ` Juri Linkov
2018-09-14  8:33           ` martin rudalics
2018-09-15 23:35             ` Juri Linkov
2018-09-16  9:10               ` martin rudalics
2018-09-16 23:49                 ` Juri Linkov
2018-09-17  6:46                   ` martin rudalics
2018-09-17 22:35                     ` Juri Linkov
2018-09-19  8:22                       ` martin rudalics [this message]
2018-09-19 23:15                         ` Juri Linkov
2018-09-20  7:34                           ` martin rudalics
2018-09-20 23:15                             ` Juri Linkov
2018-09-21  6:34                               ` martin rudalics
2018-09-22 22:15                                 ` Juri Linkov
2018-09-23  8:26                                   ` martin rudalics
2018-09-23 20:39                                     ` Juri Linkov
2018-09-24  8:22                                       ` martin rudalics
2018-09-24  8:35                                         ` Eli Zaretskii
2018-09-24 12:25                                           ` martin rudalics
2018-09-24 12:46                                             ` Eli Zaretskii
2018-09-24 17:37                                               ` martin rudalics
2018-09-24 17:53                                                 ` Eli Zaretskii
2018-09-25  7:26                                                   ` martin rudalics
2018-09-25  9:19                                                     ` Eli Zaretskii
2018-09-25 17:56                                                       ` martin rudalics
2018-09-25 18:31                                                         ` Eli Zaretskii
2018-09-24 18:38                                           ` Juri Linkov
2018-09-24 19:31                                             ` Eli Zaretskii
2018-09-25  7:27                                             ` martin rudalics
2018-09-25 19:24                                               ` Juri Linkov
2018-09-26  8:51                                                 ` martin rudalics
2018-10-27 19:38                                                   ` Juri Linkov
2018-10-28  8:59                                                     ` martin rudalics
2018-09-24 18:31                                         ` Juri Linkov
2018-09-25  7:27                                           ` martin rudalics
2018-12-26 23:42 ` Juri Linkov
2018-12-27  9:36   ` martin rudalics
2018-12-27 21:41     ` Juri Linkov
2018-12-28  8:34       ` martin rudalics
2018-12-27 15:48   ` Eli Zaretskii
2018-12-27 20:58     ` Juri Linkov
2018-12-28  4:51       ` Eli Zaretskii
2019-09-26 13:27   ` Lars Ingebrigtsen
2019-11-27 21:53     ` Juri Linkov
2019-11-28  9:20       ` martin rudalics
2019-11-28 22:50         ` Juri Linkov
2019-11-29  9:24           ` 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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=5BA20763.8070305@gmx.at \
    --to=rudalics@gmx.at \
    --cc=32672@debbugs.gnu.org \
    --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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).