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: tgbugs@gmail.com, emacs-devel@gnu.org, larsi@gnus.org
Subject: Re: [PATCH] Fix display-buffer-use-some-window to honor reusable-frames
Date: Sun, 29 Jan 2023 18:39:36 +0100	[thread overview]
Message-ID: <8af34023-d3d7-a18d-54c5-f418515dea1c@gmx.at> (raw)
In-Reply-To: <83a622abpz.fsf@gnu.org>

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

 >> We need a way to bump the time stamp of _any_ window used.
 >
 > Sorry, I don't understand what that means in practice.  Specifically,
 > what do you mean by "any window used"? used by whom and under what
 > circumstances? or do you mean any window that is currently displayed
 > on all the frames?

I mean "any window used" by 'display-buffer' to display a buffer.

 >> Otherwise,
 >> the various action functions will continue to fight each other.  Lars
 >> wanted to go the way XEmacs did but stopped in the middle.  And XEmacs
 >> uses
 >>
 >>                 (if (window-buffer window)
 >>                     (save-excursion
 >>                       (save-selected-window
 >>                         (select-window window)
 >>                         (record-buffer (window-buffer window)))))
 >>
 >> to bump the use time of every window used by 'display-buffer'.
 >
 > You mean, do this every time display-buffer is called and selects some
 > window?  But that would change our behavior for all the callers of
 > display-buffer, whose names is a legion.  Whereas the intent was to
 > provide an optional feature that hopefully doesn't affect any existing
 > behaviors.

It would change the behavior iff a user or caller had added a non-nil
'bump-time-stamp' entry to the alist.  Existing behaviors would not be
affected.

I'll give you an example.  Apply the attached bump-use-time.diff.  Now
with emacs -Q evaluate:

(let* ((window-combination-resize t))
   (split-window)
   (split-window)
   (display-buffer (get-buffer-create "*foo*"))
   (display-buffer (get-buffer-create "*bar*")))

*foo* is nowhere displayed because 'display-buffer' displayed *bar* in
the least recently used window instead.  This is the behavior Lars
wanted to avoid.

Now instead do

(let* ((window-combination-resize t))
   (split-window)
   (split-window)
   (display-buffer
    (get-buffer-create "*foo*") '(nil (bump-use-time . t)))
   (display-buffer
    (get-buffer-create "*bar*") '(nil (bump-use-time . t))))

This is the behavior Lars wanted.  Look, no separate action function
needed at all.  If anyone has a solution to that problem that's simpler
than this two-liner, I'll be all ears.

 >>   > Would it work to just temporarily select the window inside
 >>   > display-buffer-use-least-recent-window, so that its use time is bumped
 >>   > without any sneaky primitives?  Then we could remove
 >>   > window-bump-use-time.
 >>
 >> As Lars conceived it, independent 'display-buffer' calls should be able
 >> to build on previous ones.  Otherwise, we could write a function like
 >> 'display-many-buffers-at-once', within that function mark all windows
 >> used as temporarily dedicated to their buffers, and at the end restore
 >> the previous dedicated states of these windows.  Obviously, a function
 >> like 'display-many-buffers-at-once' would not qualify as buffer display
 >> action function.
 >
 > What do you mean by "independent calls"?  Or what are "dependent
 > calls" for this purpose?  Without understanding that, I cannot see how
 > what you wrote here answers my question, sorry.

A dependent call would be one inside a function like
'display-many-buffers-at-once' where you want to avoid that the same
window is used for displaying first one and then another buffer.  Any
other calls would be independent.

But to return to your question "Would it work to just temporarily select
the window inside display-buffer-use-least-recent-window, so that its
use time is bumped without any sneaky primitives?".  The XEmacs solution
cited above does precisely that and that's why I posted it here.

Why you would call a primitive like 'window-bump-use-time' "sneaky" is
beyond my comprehension.  Is it because I originally proposed it?

martin

[-- Attachment #2: bump-use-time.diff --]
[-- Type: text/x-patch, Size: 1434 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index 7d8ee48635..ef45f629c5 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7276,6 +7276,10 @@ window--display-buffer
       ;; Unless WINDOW already shows BUFFER reset its dedicated flag.
       (set-window-dedicated-p window nil)
       (set-window-buffer window buffer))
+    (when (assq 'bump-use-time alist)
+      ;; Bump WINDOW's use time so 'get-lru-window' will try to avoid
+      ;; it.
+      (window-bump-use-time window))
     (let ((alist-dedicated (assq 'dedicated alist)))
       ;; Maybe dedicate WINDOW to BUFFER if asked for.
       (cond
diff --git a/src/window.c b/src/window.c
index 90fa6ac2df..a20ac70cbf 100644
--- a/src/window.c
+++ b/src/window.c
@@ -773,13 +773,18 @@ DEFUN ("window-use-time", Fwindow_use_time, Swindow_use_time, 0, 1, 0,
 
 DEFUN ("window-bump-use-time", Fwindow_bump_use_time,
        Swindow_bump_use_time, 0, 1, 0,
-       doc: /* Mark WINDOW as having been most recently used.
+       doc: /* Mark WINDOW as most recently used after the selected window.
 WINDOW must be a live window and defaults to the selected one.  */)
   (Lisp_Object window)
 {
   struct window *w = decode_live_window (window);
+  struct window *sw = XWINDOW (selected_window);
 
-  w->use_time = ++window_select_count;
+  if (w != sw)
+    {
+      w->use_time = ++window_select_count;
+      sw->use_time = ++window_select_count;
+    }
 
   return Qnil;
 }

  reply	other threads:[~2023-01-29 17:39 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27  5:17 [PATCH] Fix display-buffer-use-some-window to honor reusable-frames Tom Gillespie
2023-01-27  5:25 ` Tom Gillespie
2023-01-27  6:19   ` Tom Gillespie
2023-01-27 13:03     ` Eli Zaretskii
2023-01-28 10:46       ` martin rudalics
2023-01-28 11:12         ` Eli Zaretskii
2023-01-28 15:35           ` martin rudalics
2023-01-28 16:02             ` Eli Zaretskii
2023-01-29 17:39               ` martin rudalics [this message]
2023-01-29 18:41                 ` Eli Zaretskii
2023-01-29 18:50                   ` Tom Gillespie
2023-01-30 16:43                   ` martin rudalics
2023-01-30 17:38                     ` Eli Zaretskii
2023-01-30 17:57                       ` martin rudalics
2023-01-30 18:04                         ` Eli Zaretskii
2023-01-31  8:45                           ` martin rudalics
2023-01-31 14:01                             ` Eli Zaretskii
2023-02-01 10:45                               ` martin rudalics
2023-02-01 17:38                                 ` Eli Zaretskii
2023-02-01 18:33                                   ` martin rudalics
2023-01-28 19:04         ` Tom Gillespie
2023-01-28 20:01           ` Tom Gillespie
2023-01-29 17:39             ` martin rudalics
2023-01-29 19:02               ` Tom Gillespie
2023-01-30 16:44                 ` martin rudalics
2023-01-30 17:43                   ` Tom Gillespie
2023-01-30 17:58                     ` martin rudalics
2023-01-30 19:40                       ` Tom Gillespie
2023-01-30 22:45                         ` Tom Gillespie
2023-01-31  8:46                           ` martin rudalics
2023-01-31 18:38                             ` Tom Gillespie
2023-02-01  9:08                               ` martin rudalics
2023-02-01 17:19                                 ` Tom Gillespie
2023-02-01 18:32                                   ` martin rudalics
2023-02-02 16:39                                     ` martin rudalics
2023-02-02 19:57                                       ` Tom Gillespie
2023-02-03  9:09                                         ` martin rudalics
2023-02-11 15:44                                           ` Eli Zaretskii
2023-02-11 18:15                                           ` Tom Gillespie
2023-02-12  9:33                                             ` martin rudalics
2023-02-18 17:46                                               ` Eli Zaretskii
2023-02-20  9:03                                                 ` martin rudalics
2023-02-20 11:55                                                   ` Eli Zaretskii
2023-02-20 18:14                                                     ` martin rudalics
2023-02-21 12:02                                                       ` Eli Zaretskii
2023-01-31  8:46                         ` martin rudalics
2023-01-29 17:48         ` Juri Linkov
2023-01-29 18:48           ` Eli Zaretskii
2023-02-06 10:01         ` 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=8af34023-d3d7-a18d-54c5-f418515dea1c@gmx.at \
    --to=rudalics@gmx.at \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=tgbugs@gmail.com \
    /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.