GNU bug report logs -
#74246
[PATCH] Reuse display windows in image-dired
Previous Next
Full log
View this message in rfc822 format
>> 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)
This bug report was last modified 182 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.