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. */
next prev parent 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).