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#74361: [PATCH] New option xref-navigation-display-window-action Date: Mon, 25 Nov 2024 19:49:40 +0200 Organization: LINKOV.NET Message-ID: <871pyzp6br.fsf@mail.linkov.net> References: <87msi1ueb0.fsf@mail.linkov.net> <4256f446-e11b-450c-b455-131cb75acab0@gutov.dev> <871pzbj8mq.fsf@mail.linkov.net> <87sernhxoa.fsf@mail.linkov.net> <1d08c589-2d0e-4f10-8c2e-e21c206ac118@gmx.at> <78a96965-31c1-4688-b808-2de09d1832c4@gmx.at> <878qt9pz4w.fsf@mail.linkov.net> <05452bef-dd2e-4e93-abdd-6eb391027197@gmx.at> <87y118cyyk.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="22570"; 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: Dmitry Gutov , 74361@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 25 18:53:27 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 1tFdH4-0005hE-DP for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 Nov 2024 18:53:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tFdGj-0002oG-1y; Mon, 25 Nov 2024 12:53: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 1tFdGg-0002m8-U1 for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2024 12:53:02 -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 1tFdGg-000205-KP for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2024 12:53: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=3q3YPvh7/K8U0Z1yOJnwliR6935p60Q5KJKkrVfE0Ck=; b=lLx7sIwqD33Hgl+qJpyX1G+/GCaUPz6JBDLrcCEE9ehTlfOXBhrdmash4I44o5bft2u5OP1BJkRtichWBDZBnl/+x0cU3z9gbDBqWTtnotMPceP97Q7lmxpbnbeCiq+7ElgRtyUgiY6sNIkD90cBYLjhuZar0PVzcZ7xcWwQKDb++f+A09yI+yZ1+ij9Q4NTWL1oz8ZYsQYIJNwlnQI2WrQCHeLoEjujThFv2D4VO7tQ73WeaxQb6dCxoyqyumdnQlUJrnvKzoSPGKJXfoWY0t0kPVFobMU2yVsiy9U4I73wSniNVQ3ynPMkz+lsJwfokWM5TpdRgVPpYEXjnPWXYA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tFdGg-0003qP-FA for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2024 12:53: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, 25 Nov 2024 17:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74361 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74361-submit@debbugs.gnu.org id=B74361.173255715914732 (code B ref 74361); Mon, 25 Nov 2024 17:53:02 +0000 Original-Received: (at 74361) by debbugs.gnu.org; 25 Nov 2024 17:52:39 +0000 Original-Received: from localhost ([127.0.0.1]:40316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFdGI-0003pX-Tn for submit@debbugs.gnu.org; Mon, 25 Nov 2024 12:52:39 -0500 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:60137) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFdGG-0003p9-OL for 74361@debbugs.gnu.org; Mon, 25 Nov 2024 12:52:37 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 8E93440002; Mon, 25 Nov 2024 17:52:08 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Mon, 25 Nov 2024 10:18:34 +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:295948 Archived-At: > We can't reasonably expect packages to set up yet another alist entry > type like 'group'. package writers just would not understand it. So it > simply _has_ to be 'category' (or something else but still only one > thing). Better to use something else. The 'category' alist entry is intended to be used only in display-buffer calls like this: (display-buffer (get-buffer-create "*info*") '(nil (category . Info-mode))) to allow using 'category' in the condition part of display-buffer-alist to match the display-buffer call: (add-to-list 'display-buffer-alist '((category . Info-mode) (display-buffer-same-window))) What you proposed is a different usage of 'category' that makes sense in the action part of display-buffer-alist: (add-to-list 'display-buffer-alist '("\*Help\*" (display-buffer-same-window) (category . Info-mode))) It would be cleaner to use a different action for this feature, e.g.: (add-to-list 'display-buffer-alist '("\*Help\*" (display-buffer-reuse-category-window) (category . Info-mode))) or without an alist entry: (add-to-list 'display-buffer-alist '("\*Help\*" (display-buffer-reuse-category-window))) > Hence any magic users might not want would have to be implemented within > 'display-buffer'. If say 'run-scheme' wants the same window, then we > already have a problem since a *scheme* window might already exist from > a previous run and it should try 'display-buffer-reuse-window' first. > But this is something for people setting up the default. > > Now if no 'inhibit-same-window' alist entry is found and the selected > window is not dedicated to another buffer, 'display-buffer' would use > the selected window as requested. No automagic here. Otherwise, it > would look for a window with a 'category' window parameter equaling > 'comint' which could, let's assume the worst, mean to use an existing > *shell* window with a running process the user might be attentively > following at that moment. But the same could happen with your proposal > as well. So any automagic here should not harm either. > > The automagic would come into play when neither caller nor user specify > a particular preference for a window or all other preferences have been > exhausted and 'display-buffer' invokes 'display-buffer-use-some-window' > (not 'display-buffer-reuse-window') in which case that function would > look for a window with a matching 'category' parameter. Which problems > do you see here? The only problem is that it will change the current default behavior, so instead of using the lru window it will prefer to use the window with the same category. I customized 'display-buffer-base-action' to use 'get-mru-window', so I won't be affected by this change, but I care about other users. Are you sure it would be expectable for users to display buffers with the same category in one window? How they could revert this behavior back to the previous default? This is why I suggest to create a separate action. If you are sure it should be used by default, then it could be inserted before display-buffer-use-some-window here: (defconst display-buffer-fallback-action '((display-buffer--maybe-same-window display-buffer-reuse-window display-buffer--maybe-pop-up-frame-or-window display-buffer-in-previous-window display-buffer-reuse-category-window ;; <-- NEW! display-buffer-use-some-window display-buffer-pop-up-frame)) Otherwise, users will be able to use the new action display-buffer-reuse-category-window in their customizations of display-buffer-alist.