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

[martin rudalics]

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