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: Thu, 12 Dec 2024 09:52:13 +0200 Organization: LINKOV.NET Message-ID: <87a5d19w42.fsf@mail.linkov.net> References: <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> <877c87o52j.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30747"; 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 Thu Dec 12 08:56: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 1tLe3Y-0007jG-W7 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 Dec 2024 08:56:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLe3J-0000RH-Kd; Thu, 12 Dec 2024 02:56: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 1tLe3H-0000R8-17 for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2024 02:56: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 1tLe3G-0001Ob-PE for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2024 02:56: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=cLR1HngAg97REx3Kg6BoOoUgU11PxygW9BANsOwRKwk=; b=nTKVxTwefrbuyIPs2R3n+Aoz2LC6RKNuLjsv2WZQe2POWt3laQX8ZPeo1D0sXFWq+LtLNO+JiM49tOjeRdHdBnnYKmh99ACE26uQdygjLEWX71ioShqXPINwTbaZTtJvaf6fxodEaZ0hOosO0eHgTIT2mISv1qHuz4GTB9Iou3G/HkeWL+58HtCfRSm0pdYFaHpDLmLCZysw7Zh1uuwjdA8UVFuo/GMzGsgCmm+zXlwowYgNkWLz7gvJaLpkDZ+n8Su+DK1g3k3vAUFA6T3Q+VJyWm0uQwbd8oEMrlgj5skF2YHCC/z/jKD8vJeo+/ih2i91yrqYrN1mEnSUIRo56Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tLe3G-0005MP-Ek for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2024 02:56: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: Thu, 12 Dec 2024 07:56: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.173399010720282 (code B ref 74246); Thu, 12 Dec 2024 07:56:02 +0000 Original-Received: (at 74246) by debbugs.gnu.org; 12 Dec 2024 07:55:07 +0000 Original-Received: from localhost ([127.0.0.1]:37466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLe2N-0005Gy-74 for submit@debbugs.gnu.org; Thu, 12 Dec 2024 02:55:07 -0500 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:46899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLe2L-0005DH-4U for 74246@debbugs.gnu.org; Thu, 12 Dec 2024 02:55:05 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 37306FF808; Thu, 12 Dec 2024 07:54:35 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Wed, 11 Dec 2024 10:38:21 +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:296890 Archived-At: >> 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. > > By having grep do the following: > > - Issue a first request to display a buffer from that list, > > - remember the window used, > > - set the local variable in the target buffer to the remembered value > before calling 'display-buffer' again. What if the user switches buffers in that window, but still wants to continue visiting next buffers from grep in the same window? >>>>> 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'. > > 'category' is much broader. > >>> 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)'. > > Let me turn the table and ask you: Both grep/xref know very well which > window was used for displaying the last match. What speaks again to > have them just remember that window after each call grep/xref should remember that window in a buffer-local variable? > and propose it via a (some-window . ,window) alist entry in the next > call together with 'display-buffer-use-some-window'? Such providing that window in the display-buffer call would be very nice to do, e.g. with a more descriptive name like (previous-window . ,window). This will make easier for users to customize by using different actions that handle such alist entry: 'display-buffer-in-previous-window' or 'display-buffer-use-some-window'. Then a category will be continued to be used only for matching, e.g. the call (display-buffer buffer `((nil (category . grep) (previous-window . ,window)))) could be customized to match a category and to use the previous window: ((category . grep) (display-buffer-in-previous-window)) > I think the main advantage of such an > approach is that grep/xref would be in complete control of a good > proposal for such a window, something most users could hardly resist. Agreed.