emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix display-buffer-use-some-window to honor reusable-frames


From: Eli Zaretskii
Subject: Re: [PATCH] Fix display-buffer-use-some-window to honor reusable-frames
Date: Sun, 29 Jan 2023 20:41:59 +0200

> Date: Sun, 29 Jan 2023 18:39:36 +0100
> Cc: tgbugs@gmail.com, emacs-devel@gnu.org, larsi@gnus.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  >> 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.

Do you mean "every window used by display-buffer"?

>  >>                 (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.

And who will add that entry?  IOW, how would this feature work, with
the patch you proposed?

> 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.

So we could make a change in display-buffer-use-least-recent-window to
temporarily select the window, and then there would be no reason for
us to artificially bump the window's use-time via window-bump-use-time?

> Why you would call a primitive like 'window-bump-use-time' "sneaky" is
> beyond my comprehension.

Because it pretends a window was selected whereas it wasn't, and
because it causes issues that you yourself pointed out (and which now
require changes to bump the use-time of the selected window as well)?

> 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;
>  }

I'm not sure I understand: is this instead of
display-buffer-use-least-recent-window, or in addition to it?  IOW,
how do you recommend we fix the issues that
display-buffer-use-least-recent-window introduced, which you mentioned
in your previous messages?

Also, with the fixes you propose, would there still be need in the
changes proposed by Tom, and if so, why?  It sounds like he is trying
to fix problems which your patches fix in a different way?

Bottom line: I'm struggling to understand what is TRT to be done about
these issues, first and foremost for Emacs 29 (since
display-buffer-use-least-recent-window is new in Emacs 29).  Would you
please help me figure that out?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]