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

[martin rudalics]

> 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