all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
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 20:41:59 +0200	[thread overview]
Message-ID: <835ycp6v48.fsf@gnu.org> (raw)
In-Reply-To: <8af34023-d3d7-a18d-54c5-f418515dea1c@gmx.at> (message from martin rudalics on Sun, 29 Jan 2023 18:39:36 +0100)

> 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	other threads:[~2023-01-29 18:41 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
2023-01-29 18:41                 ` Eli Zaretskii [this message]
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=835ycp6v48.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=rudalics@gmx.at \
    --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.