From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#74246: [PATCH] Reuse display windows in image-dired Date: Sat, 30 Nov 2024 20:03:27 +0200 Organization: LINKOV.NET Message-ID: <87y1108u9k.fsf@mail.linkov.net> References: <868qtsmydz.fsf@gnu.org> <86a5dqm9gl.fsf@gnu.org> <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@gmx.at> <87jzcn1af7.fsf@mail.linkov.net> <08f46ed1-e489-4859-8a25-ba7dc4262b95@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1714"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) Cc: Morgan Smith , Eli Zaretskii , 74246@debbugs.gnu.org, stefankangas@gmail.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 30 19:19:22 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tHS3u-0000JV-SA for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Nov 2024 19:19:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHS3d-0001LL-Kl; Sat, 30 Nov 2024 13:19:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHS3b-0001KC-UG for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 13:19:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tHS3b-0005wp-Kq for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 13:19:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=7phSDF/ypNrkeM50cI8GIA4UxerglTHHiJLkjFc8+W8=; b=dO5sbIT6PmpKZGtbVlL4dWCa2dmYb1kn9nbuetCBL9X6OvPDYHGOYoZEFz6lwMD7NcSE9L0nIII57RDdh18skeYYsdXU497qz6aG18E9yvPUhG3a+bLk5Cx6KZNLnhpR3gNelm5TnUaAcMbQ5Cgc0sNnxdiGbkgW8tYg70UJ4LkBLNGWYjGzatuRxvqHBZHF2KWyZQBpNmK8GUcEZzYAfdYfbAFTHAlPeSXwfGtaLR4rDF5vuVnMK32cAPPvilojJTfcggyJf04KbKp6fZRwfx1I0Zse3ksK4gTkJQ99pt0QXCNo/exyl3Uwnz163Pw+Hfl7A9eRzOeCI0xNqLzKGA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tHS3a-0000RS-IF for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 13:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Nov 2024 18:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74246 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74246-submit@debbugs.gnu.org id=B74246.17329906971562 (code B ref 74246); Sat, 30 Nov 2024 18:19:02 +0000 Original-Received: (at 74246) by debbugs.gnu.org; 30 Nov 2024 18:18:17 +0000 Original-Received: from localhost ([127.0.0.1]:48962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHS2r-0000P8-6E for submit@debbugs.gnu.org; Sat, 30 Nov 2024 13:18:17 -0500 Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]:38671) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHS2p-0000Om-2u for 74246@debbugs.gnu.org; Sat, 30 Nov 2024 13:18:15 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id BB37DE0004; Sat, 30 Nov 2024 18:18:07 +0000 (UTC) In-Reply-To: <08f46ed1-e489-4859-8a25-ba7dc4262b95@gmx.at> (martin rudalics's message of "Fri, 29 Nov 2024 16:53:56 +0100") X-GND-Sasl: juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296190 Archived-At: >> 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)) =