unofficial mirror of bug-gnu-emacs@gnu.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: Thu, 5 Dec 2024 10:23:40 +0100	[thread overview]
Message-ID: <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@gmx.at> (raw)
In-Reply-To: <87ikrzjrj1.fsf@mail.linkov.net>

 > 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





  reply	other threads:[~2024-12-05  9:23 UTC|newest]

Thread overview: 26+ 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 [this message]
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
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

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=b43f5cba-572e-4eaa-8359-a31ac8ca0e55@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).