GNU bug report logs - #74246
[PATCH] Reuse display windows in image-dired

Previous Next

Full log

Message #68 received at 74246 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: Morgan Smith <Morgan.J.Smith <at> outlook.com>, Eli Zaretskii <eliz <at> gnu.org>,
 74246 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
Date: Sun, 8 Dec 2024 17:55:17 +0100

> I meant that only the same command (and therefore the same
> display-buffer call) should reuse the same window.
> This is why I checked for 'this-command' in the posted snippet.
> But instead of associating with a command name an alternative approach
> would be to use a category.

One and the same command may issue an arbitrary number of
'display-buffer' calls.  Checking for 'this-command' may work for you in
a specific context but is certainly not a safe approach for general use.

> The *backtrace* buffer is not a problem because it uses own
> display-buffer alist that overrides display-buffer-use-some-window.

Unless a user has customized it or 'display-buffer-below-selected' fails
for some reason.

> display-buffer-use-some-window could recheck if the window is still suitable
> for every use of the same command and display-buffer call.

As I said above this is not reliable.  The only reliable thing is to
pass the symbol of the function calling 'display-buffer' with some
unique number identifying the nth call of 'display-buffer' within that
function.  Everything else is guesswork.

>>> 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.
>
> It's always the current buffer, even if another buffer is used
> as the source buffer.

But the current buffer may vary continuously, it might even be the
minibuffer if I issue the call from there.

> What if the user wants to display an image buffer in another window?
> Then 'display-buffer-reuse-window' can't be used.

If a user issues the command to display an image in a window that
already shows an image and insists on using another window, an arbitrary
other window can be chosen.  Users who want that just get the usual
chaotic behavior lru provides.  They asked for it.

> A buffer-local variable should be set in the source buffer only,
> not in the image buffer.

With 'image-dired' it can be set in the image buffer because that buffer
is always the same.

> I have absolutely no problems with existing code
> in 'image-dired-display-image' because of using:
>
> (setq display-buffer-base-action
>        '(nil . ((some-window
>                  . (lambda (_buffer alist)
>                      (let ((last-window (buffer-local-value
>                                          'display-buffer-last-window
>                                          (window-buffer))))
>                        (or (and (eq this-command (car last-window))
>                                 (window-live-p (cdr last-window))
>                                 (cdr last-window))
>                            (get-mru-window nil nil t))))))))

Imagine users who once they displayed an image want it to fill their
frame entirely and want to use a key combination to display the next or
previous image there.  Web pages usually display a < on the left and a >
on the right to achieve that behavior.  Image viewers put similar icons
in a toolbar for that.  There is no visible source buffer or current
buffer around for that in Emacs.  All you have is the target buffer.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.