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: Mon, 30 Jan 2023 17:43:35 +0100	[thread overview]
Message-ID: <7732128c-540b-9e38-0bf3-26c2496d2c0f@gmx.at> (raw)
In-Reply-To: <835ycp6v48.fsf@gnu.org>

 >> I mean "any window used" by 'display-buffer' to display a buffer.
 >
 > Do you mean "every window used by display-buffer"?

Yes.

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

Just as with any other action alist entry as listed in section 29.15.3
of the Elisp manual.  The example I gave shows what an application can
do to get the behavior wanted in Bug#45688.  If someone comes up with
another example, I can try to tell how to solve that.

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

You would still "artificially bump the window's use time".  Just that
you would also make its buffer current, swap in its local variables,
mark windows for redisplay, maybe select another frame, move minibuffers
onto that frame, resize the minibuffer window ...  And then repeat all
that in order to reselect the previously selected window.  And at the
very end blame the WM when it raised a frame where all we wanted to do
was to change the use time of one of our windows.

Emacs with a separate minibuffer frame is broken here for almost a year
because someone does "temporarily select the window" and because
'select-window' now behaves in a way it never did.  I know that I'm
fighting against windmills here.  'select-window' is too heavyweight.
It should be reserved for the user to choose another window to work in.

 >> 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 having 'display-buffer' select a window for the sole purpose to bump
its use time would not pretend anything?

 > (and which now
 > require changes to bump the use-time of the selected window as well)?

You would have to do that also when you explicitly select the window.

 > I'm not sure I understand: is this instead of
 > display-buffer-use-least-recent-window, or in addition to it?

It would be a lightweight alternative.

 > IOW,
 > how do you recommend we fix the issues that
 > display-buffer-use-least-recent-window introduced, which you mentioned
 > in your previous messages?

AFAICT Tom is trying to fix them.

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

'display-buffer-use-least-recent-window' is here since Emacs 28 so I
think that Tom's changes are needed.  What Tom is proposing is to have
'display-buffer-use-least-recent-window' encompass the behaviors of
'display-buffer-reuse-window' and 'display-buffer-pop-up-window' in
order to bump use times in these cases too.  My patch bumps use times
for every buffer display action once a 'bump-use-time' entry has been
added.

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

'display-buffer-use-least-recent-window' is not new in Emacs 29.  Let's
wait for Tom to work out a fix for that.

martin



  parent reply	other threads:[~2023-01-30 16:43 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
2023-01-29 18:50                   ` Tom Gillespie
2023-01-30 16:43                   ` martin rudalics [this message]
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=7732128c-540b-9e38-0bf3-26c2496d2c0f@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.