all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Juri Linkov <juri@linkov.net>
Cc: Morgan Smith <Morgan.J.Smith@outlook.com>,
	Eli Zaretskii <eliz@gnu.org>,
	74246@debbugs.gnu.org, stefankangas@gmail.com
Subject: bug#74246: [PATCH] Reuse display windows in image-dired
Date: Sun, 8 Dec 2024 17:55:17 +0100	[thread overview]
Message-ID: <7a548d2f-144b-45e3-9558-8908a2a4a86b@gmx.at> (raw)
In-Reply-To: <87ed2jwhm5.fsf@mail.linkov.net>

 > 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





  reply	other threads:[~2024-12-08 16:55 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07 20:19 bug#74246: [PATCH] Reuse display windows in image-dired Morgan Smith
2024-11-09 11:37 ` Eli Zaretskii
2024-11-09 17:36   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-23 12:16     ` Eli Zaretskii
2024-11-28  0:32       ` Morgan Smith
2024-11-28  9:28         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-28 18:27           ` Juri Linkov
2024-11-29 15:53             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-30 18:03               ` Juri Linkov
2024-12-01  8:46                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-02  7:42                   ` Juri Linkov
2024-12-02 11:22                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-03  7:47                       ` Juri Linkov
2024-12-03  8:25                         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-03 17:24                           ` Juri Linkov
2024-12-04  7:59                             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-04 17:18                               ` Juri Linkov
2024-12-05  9:23                                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-05 17:54                                   ` Juri Linkov
2024-12-06  8:33                                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-07 17:13                                       ` Juri Linkov
2024-12-08 16:55                                         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-12-09 19:16                                           ` Juri Linkov
2024-12-10 15:55                                             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-10 17:30                                               ` Juri Linkov
2024-12-11  9:38                                                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-12  7:52                                                   ` Juri Linkov
2024-12-12  9:23                                                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-12 16:40                                                       ` Juri Linkov
2024-12-12 17:24                                                         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-12 18:42                                                           ` Juri Linkov
2024-12-13  9:19                                                             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-14 18:19                                                               ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7a548d2f-144b-45e3-9558-8908a2a4a86b@gmx.at \
    --to=bug-gnu-emacs@gnu.org \
    --cc=74246@debbugs.gnu.org \
    --cc=Morgan.J.Smith@outlook.com \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    --cc=rudalics@gmx.at \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.