From: Juri Linkov <juri@linkov.net>
To: martin rudalics <rudalics@gmx.at>
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: Sat, 30 Nov 2024 20:03:27 +0200 [thread overview]
Message-ID: <87y1108u9k.fsf@mail.linkov.net> (raw)
In-Reply-To: <08f46ed1-e489-4859-8a25-ba7dc4262b95@gmx.at> (martin rudalics's message of "Fri, 29 Nov 2024 16:53:56 +0100")
>> So in conclusion it seems better to reuse 'category' in
>> display-buffer-use-some-window. But not to set the window parameter
>> 'category' in window--display-buffer unnecessarily. Instead
>> this window parameter could be set only in display-buffer-use-some-window
>> when failing to find a window with a category. I mean something like this
>> in display-buffer-use-some-window
>>
>> (if (get-window-with-category category 'visible nil not-this-window)
>> (use window with category)
>> ;; otherwise
>> (use lru window by default)
>> (set-window-parameter window 'category (cons category parameter)))
>
> And who would set up the 'category' parameter for the first window used
> by 'image-dired'? In my initial proposal, the presence of a 'category'
> parameter would mean to _always_ set the parameter for the window used.
> And I even would have the value of the parameter made a list like
> '(category . (tex-shell comint)) if that window would have been used for
> both.
I agree with the need to set the window parameter always.
For example, I often use commands that override the default action
with e.g. windmove-display-up/down, etc. Therefore needed
to add an advice that remembers the last window in the
buffer-local variable:
(defvar-local display-buffer-last-window nil)
(define-advice display-buffer-record-window (:after (type window buffer) set-last-window)
(with-current-buffer (window-buffer)
;; TODO: maybe later turn cons into alist ((COMMAND1 . WINDOW1) (COMMAND2 . WINDOW2))
(setq-local display-buffer-last-window (cons this-command window))))
(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))))))))
This uses the buffer-local variable in the original buffer
because IIUC setting a window parameter like in your patch
can create such a situation that more than one window
will have the same window parameter. But need to keep
only one unique parameter in the last window that displayed
the buffer.
> Another question: Would it make sense to have 'image-dired' do
>
> (display-buffer buf '(nil ((some-window . mru))))
>
> in a first phase before embarking on a more complex solution?
This looks like the best immediate solution.
However, I still like your proposal to use a category instead of lru,
that could be used here later as well.
> Or better
>
> (display-buffer
> buf '(nil ((some-window . mru) (inhibit-same-window . t))))
>
> to make sure the selected window doesn't get used?
But get-mru-window already prevents selecting the selected window
by the arg NOT-SELECTED of get-mru-window in display-buffer-use-some-window:
((eq some-window-method 'mru)
(get-mru-window nil nil t))
=
prev parent reply other threads:[~2024-11-30 18:03 UTC|newest]
Thread overview: 9+ 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 [this message]
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=87y1108u9k.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=74246@debbugs.gnu.org \
--cc=Morgan.J.Smith@outlook.com \
--cc=eliz@gnu.org \
--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).