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: Tue, 10 Dec 2024 19:30:28 +0200 Organization: LINKOV.NET Message-ID: <877c87o52j.fsf@mail.linkov.net> References: <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> <875xnsll9k.fsf@mail.linkov.net> <24d8f9ec-788b-4bff-a67f-ccfbca1da725@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="7490"; 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 Tue Dec 10 18:50:50 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 1tL4Nl-0001nd-Re for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Dec 2024 18:50:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tL4N4-0005Bm-Ke; Tue, 10 Dec 2024 12:50: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 1tL4N1-00055A-7p for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 12:50: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 1tL4N0-0007bt-Uw for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 12:50:02 -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=ns9UI94NOP8sMG/ZESRKfuM3E8wWGyUDMbSVVOIpD0w=; b=fLZi0GJnH5iiK0gWFc7Jcayj6aOlsVn5OtjrR1u/MjB14io7UJ5dmxDXePCymmagIHbcxFmDjzWplEfsq0O8q5kwXgY5OOxzdqcjdLGNXHQMT3VdwIDr6JvzUwdTcwfRjiMEhcK3afyQPlPdgmzszxcjrXfTA0pN5Gym4gnyrB9/gNjtGhOl0G9z1SYPJWcwP0ZIBa8XRPgqVzJ3GpNBVJgQR6tUKBeE0AqRiW1lbYEznLqtEQ90wossz3GJURodJOL8MPrrmcNefbyBlGdojQTPMjb7R5nrBrLcXwpIaOQoJfSvJQFHBgoMG0IqwHjGdhlRYqFyiDj0TbqIjE0cNw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tL4N0-0002CD-Ob for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 12:50: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: Tue, 10 Dec 2024 17:50: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.17338529428296 (code B ref 74246); Tue, 10 Dec 2024 17:50:02 +0000 Original-Received: (at 74246) by debbugs.gnu.org; 10 Dec 2024 17:49:02 +0000 Original-Received: from localhost ([127.0.0.1]:59481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tL4M2-00029k-As for submit@debbugs.gnu.org; Tue, 10 Dec 2024 12:49:02 -0500 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]:38545) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tL4M1-00029B-25 for 74246@debbugs.gnu.org; Tue, 10 Dec 2024 12:49:01 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id BA8EAC0005; Tue, 10 Dec 2024 17:48:51 +0000 (UTC) In-Reply-To: <24d8f9ec-788b-4bff-a67f-ccfbca1da725@gmx.at> (martin rudalics's message of "Tue, 10 Dec 2024 16:55:32 +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:296774 Archived-At: >> What would be the safest approach to detect the same 'display-buffer' call? >> A category? > > As I already mentioned: The calling function would have to reserve a > separate alist entry for it. In my initial proposal I had even a > separate argument for that purpose. Alternatively, one could reserve a > local variable in the target buffer for that purpose ('display-buffer' > would have to reset it). I still don't understand how a local variable in one target buffer could help to display another buffer in the same window from grep/xref list. >>> 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. > > Would you like that? I think displaying *backtrace* in the same window > is always a bad idea. Only when 'display-buffer-below-selected' fails that is extremely rare. >>> 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'. > > But this one is already handled by 'buffer-match-p'. We can't set it > willy-nilly to some arbitrary value. Otherwise, that function might > match it in an unexpected way. 'display-buffer-reuse-category-window' could reuse the 'category' symbol. Or '(some-window . reuse-category)'. >>> 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. > > Yes. But then either of the windows could be chosen by the next call > (if that window still exists). Not either, but preferably the last used window. >>> 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. > > 'image-dired' _is_ different because it always uses the same buffer for > showing images stored in different files. I know of no other function > doing that. Do you? I don't remember any other function doing such non-standard things.