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: Mon, 09 Dec 2024 21:16:39 +0200 Organization: LINKOV.NET Message-ID: <875xnsll9k.fsf@mail.linkov.net> References: <86a5dqm9gl.fsf@gnu.org> <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@gmx.at> <87jzcn1af7.fsf@mail.linkov.net> <08f46ed1-e489-4859-8a25-ba7dc4262b95@gmx.at> <87y1108u9k.fsf@mail.linkov.net> <87ldwyil8q.fsf@mail.linkov.net> <3a5afa37-0ea1-4183-a563-ecc3067818c2@gmx.at> <871pypb43g.fsf@mail.linkov.net> <8cd0088f-1beb-4871-a06c-17f8cfb23e29@gmx.at> <87plm8addt.fsf@mail.linkov.net> <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@gmx.at> <87ikrzjrj1.fsf@mail.linkov.net> <87cyi6f2gb.fsf@mail.linkov.net> <6689d418-d028-40b8-b3d2-4ff12fe4283a@gmx.at> <87ed2jwhm5.fsf@mail.linkov.net> <7a548d2f-144b-45e3-9558-8908a2a4a86b@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="25674"; 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 Mon Dec 09 20:20:33 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 1tKjJ3-0006a9-70 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 09 Dec 2024 20:20:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKjIc-0002j0-4D; Mon, 09 Dec 2024 14:20:06 -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 1tKjIZ-0002if-G9 for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2024 14:20: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 1tKjIZ-0003A9-6V for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2024 14:20: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=c6MjYwa/o2XxVUpdrt9VhJnnQe/GGLwtK1JM89sHNGM=; b=lZrS8Y1uln0HAkuRbPQ45nNHC5FBf9O4fHgw4i3Egv4bwDfpM7SIxQTavihtyfb9WI2D4AxwSfbcSChAIr4FzkAuLq5m8+eRU3c0urqSsdPK4ZfsRaqhyZ5xQ0X8dmckvmsk9L2MOVaD+aQhbJIYMsC/DX7h7/Q6IgN+mfK+qY/yG83bjJx78KM6+/AGi43qWSSndy6+alqsNlL4kKWDUG3+ZmlXNfpyheLuQB0jrvPiJHyyWlXG5JNyAsP/S4srsY4+DHfiyV3BPHjd/u5g57tL8J5vZCmft21oRv3qgIoSOqo7njC7JuEK8RCVtyyJ3RjKnexccLEFNwAapI2EyA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tKjIY-00083n-29 for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2024 14:20: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: Mon, 09 Dec 2024 19:20: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.173377199030949 (code B ref 74246); Mon, 09 Dec 2024 19:20:02 +0000 Original-Received: (at 74246) by debbugs.gnu.org; 9 Dec 2024 19:19:50 +0000 Original-Received: from localhost ([127.0.0.1]:55675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKjIL-000836-0U for submit@debbugs.gnu.org; Mon, 09 Dec 2024 14:19:49 -0500 Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]:56895) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKjII-00082m-Gy for 74246@debbugs.gnu.org; Mon, 09 Dec 2024 14:19:48 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id EF9D3E0006; Mon, 9 Dec 2024 19:19:37 +0000 (UTC) In-Reply-To: <7a548d2f-144b-45e3-9558-8908a2a4a86b@gmx.at> (martin rudalics's message of "Sun, 8 Dec 2024 17:55:17 +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:296717 Archived-At: >> 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. What would be the safest approach to detect the same 'display-buffer' call? A category? >> 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. Then displaying it by some-window in the same window instead of lru looks as a nice thing to do. >> 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. There is already such a symbol: 'category'. >>>> 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. The users might want to switch displaying to another window, and continue displaying other images in the same other window. >> 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. This is an exception, not a general rule such as for navigating grep/xref results. I see no reason for image-dired be different from grep/xref.