From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74361: [PATCH] New option xref-navigation-display-window-action Date: Fri, 22 Nov 2024 10:22:05 +0100 Message-ID: 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> Reply-To: martin rudalics Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17271"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 74361@debbugs.gnu.org To: Dmitry Gutov , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 22 10:23:26 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 1tEPsq-0004LG-HA for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Nov 2024 10:23:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tEPsX-0006Dv-2Y; Fri, 22 Nov 2024 04:23: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 1tEPsU-0006DR-6j for bug-gnu-emacs@gnu.org; Fri, 22 Nov 2024 04:23: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 1tEPsT-0002rQ-SK for bug-gnu-emacs@gnu.org; Fri, 22 Nov 2024 04:23:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=ZxkSocxilXf/1HtQsXefu8mp58TsIHp4tDHr8pfmc2Q=; b=dV9XILLx5l+uThZuYP09Qo5SEznVbk/RYV8hT4ze9PiubRXGadOVuxLnjsg6a/vDpRya2Sa49aYahImQQAAy7xdYHKxNKJLDM3PvfpYuSDBpzffxziOWaTniRQ6guLqVA/2pSzBhNmqje16I1hFBrRpVFPcqFSfd7YACUpf6ZbkMMBhOc+vmxEVXOBUXMpLITKGzXBK7r8I4dvOfTd1Gsv5qupFMUE7lnzRmJLF/RA7+mTk6td7F7vYeMDFPSFUJhIcTgtgFZWKVlhYVig5kY5XsyEfQtFy2VRKV3Q9TOKut/WG06dHeXEJsEEY93ogZyqsr273YemGex1zpH5qx8Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tEPsT-0007n4-N1 for bug-gnu-emacs@gnu.org; Fri, 22 Nov 2024 04:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Nov 2024 09:23:01 +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.173226733929879 (code B ref 74361); Fri, 22 Nov 2024 09:23:01 +0000 Original-Received: (at 74361) by debbugs.gnu.org; 22 Nov 2024 09:22:19 +0000 Original-Received: from localhost ([127.0.0.1]:53043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEPrm-0007lr-Hj for submit@debbugs.gnu.org; Fri, 22 Nov 2024 04:22:18 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:60939) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEPrj-0007la-Vi for 74361@debbugs.gnu.org; Fri, 22 Nov 2024 04:22:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1732267327; x=1732872127; i=rudalics@gmx.at; bh=ZxkSocxilXf/1HtQsXefu8mp58TsIHp4tDHr8pfmc2Q=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=KbeWteqAYh5wqBZaIUD94v4aKCTHm9q/oodHVA6mIFjdZLjR2z+DxClsdsPFh8xB gVeZpDj4aSXPyCKEEm2uxeIk3KHunsF0Z6VqFawZl/ExwVWzLlXGjuyEqz9Cgl4Av U9n/0Wm0muyDKwvkJzMXqNCweRs3ThHJIc9A2ed55kdFhfNW1g3n2k9ESUf9qWAI6 O4ma8P3/TErxNLAjCcNSTJXnM1qU3MuI1UENvr2bXVquAQxAJt9Bi1R6jzWaQf6je WInVUK3Vxk9+hcUKpimQAc+Z27b5YeNTf1XOefhbjTranenaH+PC94T8htu6ADiHQ HEhcqs6+zU8t3wQGGw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([212.95.5.70]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MpDNf-1u57D73xKJ-00dgY0; Fri, 22 Nov 2024 10:22:07 +0100 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:winrgJRrfAgeQk8nuQY0ExWFg/7/5jXfKlFPHhaixWGmw9gGGqh 2fqEEBkCxjXXzqisnnbEVcwlmbUgRgReXx+lKzphgLpZP62IuVx+TnM+Ch/eBw0Bsp2bkYP V1cn/ASiN3KpHeZLCqg+zecUOG2Ef+d0JXXUAWyQmrgvP7it3tLoS0DXLy75wvm3hlqe2U7 +Uo289B75RK73l6cj0OtQ== UI-OutboundReport: notjunk:1;M01:P0:VHS0sSxNHdc=;YmAZgx1ppOjVGyfIpm3BCLxcvWM 1r5uj8TPNQMwy4nXWvRSIJxfWD3fNzOBisQQLh37izknElJaPDOXX1XE7M883y44yCFArs1fc wJAI8KsV32qaCJpaaSkrJ6DkFgTLJrt5d/0tBS3Il6VyXfVOjPYhL8P50AfTja8RQowi9XzrL gdGljc6hlgfJ4sQGXGMfK+zInrXdlcXuPJmBSMPwTDETgbsDTr/wmMW1ZPwsu3PFQw4+KtdBr 1tqEbJT9lh9IvSF5t9pEsaM89bb7TlHH0weGeC2cAsIqCYqxL5d2pw+wGi1kK30lOqin+fAQc d2OnLN3RxZHwot046xDT8NKnxncxvvYEgpV7zfCmoQ1aLofRvNV4Npd0QDzoLuJrrwrdIzUFC hfNSpJ7GunoRQ7+rDP9tIlyC3gdaVgJ+oB1NpRLqfSEEoev/jfHoRxMMX/cjQtswZJSIj/c7p 95eI7fpkvQVaVU3EA5VnhwyOAtduYqcQRPDtOK9QAVkvcIgoM9P92ddYXRveS7TJYNAZHrcl+ HQjJ5iy5SyCXwwneJJhBe1WdzijDUZEaXNUAdmnc/0ipxZwucHsci6Nx0F1ZRO2jXByUlrw9W vcHlZP7rdc7it6zV2AJzlry0ZpMZpR7P9cMrG/zUal9i99jY3Kw1DM9YHXXVk3JnbcxWjdmZ8 v9RHcmm4GxYIu+xiKUooDmXQLPKeTaTy+p2MPLLJ3AG3SwixM/d3kEq7lsqP2r9e5yZajQDxq D2q17yTowDytT95YMDtM/f77+JfYvXzApByH9N6ifTkZi+eW2SCYqS+7KNiF1CwBGnoNUhGC 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:295783 Archived-At: >> I think that the most important improvement of "category" should be to >> override "lru". > > The customization capability, you mean? Nice to have indeed. What I meant was the following: Calling 'get-lru-window' in 'display-buffer-use-some-window' is a heritage from the times when 'display-buffer' was implemented in C. It was hard-coded there and could not be customized. And it conceptually made sense with multiple windows because the lru window should be the one whose contents a user could most likely dispense with. And it can even work when multiple 'display-buffer' calls are invoked in one and the same command. The idea misfires in one case: When a user wants one and the same window display several buffers in sequence. These buffers could represent images resulting from browsing an image directory or files containing grep or xref hits or sources of compile errors. Anything a user might want to browse sequentially or, with other words, things a user might not want to look at at the same time. In these cases, the lru window will change continuously when multiple windows are present. Now if these related buffers were made subject of a common category and that category were passed as argument to 'display-buffer-use-some-window', the latter could decide - if a window showing a buffer belonging to the same category existed already - to use that window instead of the lru one. Obviously, someone has to decide on setting up the name of the category. This is the task of the caller of 'display-buffer' - 'image', 'xref', 'grep', 'compile', 'comint' or 'tex' - and would have to be done in a coordinated fashion so the same category is used twice iff that's really intended. In either case, 'display-buffer' would look whether an appropriate window exists and use that window, maybe also ignoring certain aspects (dedicatedness, minimum size) that would otherwise prevent its use. An orthogonal issue is whether an initial command expresses the desire to show the buffer in "another" window or on "another" frame. My suggestion would be to have these suppress any 'category' argument and have 'display-buffer' proceed as usual, that is use the lru window on the specified frame , pop up a new frame ... martin