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

[martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

 > The drawback of reusing 'category' for other purposes is that
 > all current display-buffer calls that provide a category,
 > will set the window parameter 'category' unnecessarily.

Correct.  And affect the 'lru' behavior.

 > OTOH, the drawback of using a separate name is that many calls
 > will have to duplicate the same name as e.g.
 >
 >    (display-buffer buffer '(nil (category . image-dired)
 >                                 (parameter . image-dired)))

We could make 'parameter' do both such that it has the matching behavior
of 'category' and also adds a parameter.  It's a question of describing
it in a way people understand.

 >> - Allow for the value of the existing 'some-window' alist entry to be
 >>    specified as a string like
 >>
 >>    (pop-to-buffer buf '(nil (some-window . "image-dired")))
 >>
 >>    Slightly unnatural, but I see no harm with it.
 >
 > This makes such sense that if it has to find some window
 > then let it be the same some-window from previous calls.
 >
 > But it has the same problem as above that many calls should
 > duplicate the name
 >
 >    (display-buffer buffer '(nil (category . image-dired)
 >                                 (some-window . "image-dired")))
 >

Right.

 >> - Use a new alist entry, say "parameter" like
 >>
 >>    (pop-to-buffer buf '(nil (parameter . image-dired)))
 >>
 >>    More intuitive maybe.  People would have to learn about it.
 >
 > An alternative name would be '(group . image-dired)'  Still
 > the same problem as above:
 >
 >    (display-buffer buffer '(nil (category . image-dired)
 >                                 (group . image-dired)))

Right.

 >> - Write a new action function 'display-buffer-use-window-with-parameter'
 >>    and use it in conjunction with the previous as
 >>
 >>    (pop-to-buffer
 >>      buf '(display-buffer-use-window-with-parameter (parameter . image-dired)))
 >>
 >>    Probably the most universal approach but people have to learn about a
 >>    new action function + alist entry.
 >
 > This is the explicit and easy to understand.  But too limiting.
 > display-buffer/pop-to-buffer calls should still use the nil action.

The nil action doesn't come without its pitfalls either.  If, as a
caller, I use an explicit action, I at least live in the (possibly
false) hope that my alist entry affects that function and only that
function.  With nil I have to study all action functions in order to
understand whether my alist entry could have any effect and where.

 > So in conclusion it seems better to reuse 'category' in
 > display-buffer-use-some-window.  But not to set the window parameter
 > 'category' in window--display-buffer unnecessarily.  Instead
 > this window parameter could be set only in display-buffer-use-some-window
 > when failing to find a window with a category.  I mean something like this
 > in display-buffer-use-some-window
 >
 >    (if (get-window-with-category category 'visible nil not-this-window)
 >        (use window with category)
 >      ;; otherwise
 >      (use lru window by default)
 >      (set-window-parameter window 'category (cons category parameter)))

And who would set up the 'category' parameter for the first window used
by 'image-dired'?  In my initial proposal, the presence of a 'category'
parameter would mean to _always_ set the parameter for the window used.
And I even would have the value of the parameter made a list like
'(category . (tex-shell comint)) if that window would have been used for
both.

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

(display-buffer
   buf '(nil ((some-window . mru) (inhibit-same-window . t))))

to make sure the selected window doesn't get used?

martin