Subject: bug#74246: [PATCH] Reuse display windows in image-dired

From: martin rudalics <[email-masked]>
Date: Sun, 1 Dec 2024 09:46:18 +0100

> I agree with the need to set the window parameter always.
 > For example, I often use commands that override the default action
 > with e.g. windmove-display-up/down, etc.  Therefore needed
 > to add an advice that remembers the last window in the
 > buffer-local variable:
 >
 > (defvar-local display-buffer-last-window nil)

Let's define it via DEFVAR_PER_BUFFER in buffer.c and have
'window--display-buffer' always set it.
'display-buffer-use-some-window' then could use it either by default or
if it finds a 'some-window' entry whose cdr is nil or t or whatever we
want.

 > This uses the buffer-local variable in the original buffer
 > because IIUC setting a window parameter like in your patch
 > can create such a situation that more than one window
 > will have the same window parameter.

Which is no harm per se.  But it should be possible to exploit it
somehow.

 >> Another question: Would it make sense to have 'image-dired' do
 >>
 >> (display-buffer buf '(nil ((some-window . mru))))
 >>
 >> in a first phase before embarking on a more complex solution?
 >
 > This looks like the best immediate solution.

Morgan, can you try that?

 > However, I still like your proposal to use a category instead of lru,
 > that could be used here later as well.

With 'image-dired' 'display-buffer-last-window' wouldn't help.  But
'image-dired' could define a mode-local variable, say
'image-dired-last-window', and propose that as 'some-window'.  We could
make 'some-window-method' accept a live window for that purpose.

 > But get-mru-window already prevents selecting the selected window
 > by the arg NOT-SELECTED of get-mru-window in display-buffer-use-some-window:
 >
 >    ((eq some-window-method 'mru)
 >     (get-mru-window nil nil t))
 >                             =

I thought so but was too lazy to countercheck.

martin