GNU bug report logs -
#74246
[PATCH] Reuse display windows in image-dired
Previous Next
Full log
Message #56 received at 74246 <at> debbugs.gnu.org (full text, mbox):
> 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?
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?
Then let's store the last window chosen in a buffer-local variable say
'last-window'. This can be either done in the target buffer as
DEFVAR_PER_BUFFER ("last-window", &BVAR (current_buffer, last_window),
Qnil,
doc: /* Last window showing this buffer via `display-buffer'..
This is the last window used by `display-buffer' for showing this buffer.
It is used by `display-buffer-use-some-window' for displaying this
buffer in that window. */);
or in the source buffer as
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 first specification has the following two drawbacks. The caller of
'display-buffer' would have to initialize it in a target buffer that has
not been shown before to the window that has previously shown an element
of the list. Also, it's somehow redundant since 'window-prev-buffers'
called on all windows could find that window as well if the target
buffer has already been displayed anywhere.
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.
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.
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?
martin
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.