GNU bug report logs -
#74246
[PATCH] Reuse display windows in image-dired
Previous Next
Full log
Message #62 received at 74246 <at> debbugs.gnu.org (full text, mbox):
>> 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?
You mean that is uses the same window? There cannot be such a
guarantee. That window might have been (de-)selected, (temporarily)
deleted, made dedicated and for any such reason may have become
unsuitable for 'display-buffer'. In the course of years people have
added more and more conditions why 'display-buffer' should avoid certain
windows. Think of 'display-buffer-avoid-small-windows' - a global
option that completely sidesteps the internal alist concept.
> 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.
I have no idea of a secure way to retrieve that buffer.
> 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.
Whatever we do: The buffer-local variable would have to be an option to
fix the existing misbehavior of lru. And it should be used only in
cases where 'display-buffer-reuse-window' can't find a suitable windows.
'image-dired' could safely use 'display-buffer-reuse-window' because it
eventually displays its images always in the same buffer. It cannot do
that right away in its present version because that one does ...
(let ((buf (get-buffer image-dired-display-image-buffer))
(cur-win (selected-window)))
(when buf
(kill-buffer buf))
(when-let ((buf (find-file-noselect file nil t)))
(pop-to-buffer buf)
... first pop up a buffer showing 'file' which means that
'display-buffer-reuse-window' usually won't find such a window ...
(rename-buffer image-dired-display-image-buffer)
... and then renames that buffer to 'image-dired-display-image-buffer' -
a buffer that 'display-buffer-reuse-window' would have found if it has
been displayed at least once. Note that the present lru mischief
doesn't happen for the first image displayed. It happens for successive
image displays only, where 'image-dired-display-image-buffer' has been
already displayed at least once.
And note the 'kill-buffer' killing 'image-dired-display-image-buffer'.
That one defies any attempt to set a buffer-local variable in that
buffer.
> 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)
I would have to understand the semantics of 'reuse' first. What
'display-buffer' cannot handle currently is something like the
'image-dired' scenario above where the buffer would not be renamed. In
that case it would be nice if the caller could set a 'category' or a
'some-window' alist entry and 'display-buffer' could use that to find a
window with the same 'category' or 'some-window' value and display the
buffer there.
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.