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

[Juri Linkov <juri@linkov.net>]

>> In all customizations I relied on the assumption that the source buffer
>> was current and its window was selected.  And indeed I see the uses
>> of '(eq window (selected-window))' in display-buffer functions.
>
> Let's assume a "source buffer" containing a list of objects (usually
> links to files possibly enhanced with positions in them) a user might
> want to display in a buffer.  These files could be source files
> containing definitions or compiler errors, images or simply all files in
> a directory.  A user might want to navigate that list to display a
> "target buffer" showing the next or previous object with respect to the
> current object of that list.  Do we agree on that?

Agree.

> If the function for showing the next of previous object in the list is
> `display-buffer', then if 'display-buffer-use-some-window' is called to
> find a suitable window and there are several windows on the selected
> frame, it would be nice if always the same window were chosen for
> displaying the target buffer instead of using the lru window with the
> consequence that the next object in the list is always shown in another
> window.  Hence some way to remember the last window chosen and use it
> again in the next call would be a nice idea.  The proposed way to do
> that is by using a buffer-local variable.  Do we agree on that as well?

Agree.

>   DEFVAR_PER_BUFFER ("last-window", &BVAR (current_buffer, last_window),
> 		     Qnil,
> 		     doc: /* Last window showing a buffer via `display-buffer'.
> This is the last window used by `display-buffer' for showing a buffer
> invoked by a function with this buffer current.  It is used by
> `display-buffer-use-some-window' for displaying its buffer argument in
> that window.  */);
>
> The second specification has the drawback that _any_ 'display-buffer'
> call that relies on 'display-buffer-use-some-window' may use that
> window.  Just think of an error occurring during that call: The
> *backtrace* buffer will pop up in the window specified by that variable
> although it is by no means related to it.

Indeed, this is not good.  So only a category can ensure that
the same display-buffer call is used?

> Moreover, in the implementations proposed for setting it so far,
> 'window--display-buffer' would set that variable locally in the buffer
> of the window selected before calling 'display-buffer'.  This implies
> that the source buffer must appear in the selected window and would
> preclude the use of a key binding that works even if the source buffer
> is currently not displayed in any window.

It's fine to set a buffer-local variable in the buffer where the user
types a key that displays the target buffer from another source buffer.
As long as the same buffer is used to get the value of this variable.

> Obviously, we could also ask for the caller to pass the window to use in
> a 'previous-window' or 'some-window' alist entry and set the window
> previously used in some non-local variable pertinent to the caller.  But
> then why use a buffer-local variable in the first place?  What am I
> missing?

There are two goals:

1. replace the current lru with another default that reuses a previous window.
   But not complicating all exiting display-buffer calls by requiring
   each of them to set a buffer-local variable.  When a standard variable
   will be set, then it can be shared by different calls.

2. make user customization easy by using a special symbol like
   '(some-window . reuse).  But directly using the variable
   is also fine, e.g. `(some-window . ,last-window)