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#74246: [PATCH] Reuse display windows in image-dired Date: Fri, 29 Nov 2024 16:53:56 +0100 Message-ID: <08f46ed1-e489-4859-8a25-ba7dc4262b95@gmx.at> References: <868qtsmydz.fsf@gnu.org> <86a5dqm9gl.fsf@gnu.org> <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@gmx.at> <87jzcn1af7.fsf@mail.linkov.net> 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="26108"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Morgan Smith , Eli Zaretskii , 74246@debbugs.gnu.org, stefankangas@gmail.com To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 29 16:55:34 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 1tH3LB-0006ce-En for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Nov 2024 16:55:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tH3Kj-0006AZ-Bi; Fri, 29 Nov 2024 10:55: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 1tH3Kg-00068E-UG for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2024 10:55: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 1tH3Kg-0005Wr-Le for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2024 10:55:02 -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=CuJdb1ZS7Ckwrfj4FX3sesbkBtrRC12ARGf7Ft3/P60=; b=OqJrMdUSWiUc4IrwrymRS6eJgsPp4Ouol+4x9N2w2aFNmnwRpp2f98seTYruW/wWWCOsnWgpDlHTkA7QJbG7TRqSajNXuT+y4q/gqTlap+dFbhZmyIdeoMP3+fLHYfrYrJHqX9Z8M+L1DIHuscPsMABKpP04LndeBS0TbAJpvbqIfG1QBAJ52aykbAin6X4pAjhxW98bzD6TZP6z9bekxSF2xeV5L/qzxrsg9ZV6GUlvl5mXFptPzaV0oNlPwWHLrHuWOQUoVs8zkVv58nt6Ug/ddkHGx37l55oUM9TkLivjycJsfHj4ZwKLCm3iIXsERzHj4ZQOarcKGHgHt6h6cg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tH3Kg-00084H-BO for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2024 10:55:02 -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, 29 Nov 2024 15:55: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.173289565030917 (code B ref 74246); Fri, 29 Nov 2024 15:55:02 +0000 Original-Received: (at 74246) by debbugs.gnu.org; 29 Nov 2024 15:54:10 +0000 Original-Received: from localhost ([127.0.0.1]:44132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tH3Jp-00082Z-GU for submit@debbugs.gnu.org; Fri, 29 Nov 2024 10:54:10 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:48703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tH3Jn-00081y-Ab for 74246@debbugs.gnu.org; Fri, 29 Nov 2024 10:54:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1732895638; x=1733500438; i=rudalics@gmx.at; bh=CuJdb1ZS7Ckwrfj4FX3sesbkBtrRC12ARGf7Ft3/P60=; 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=I1zCs80bI/Re1YwglCRQkPDKdZ1ophgerrWlzUGnHk+9RGPaInmxKcGmRmLdiqJf OnTh+FwkndEecM0FaX8aiCuDq6CrrO/Knj7Z33E42fAX4tGZpwBb96BvxpFCLWn9C s0g1ajvsuMi9VhXnBFjXR1+oRwnPh6g35kFRd700s07YBQHiPQSU3Bt1s/NTTFDYm 2aF72RGltuIw1ME70WR0BJozc3ZfWsjBel4FAyGORfjd3Yq3/kDJh02gxPh+Wk/Wd e/Qtj9nsjq3q3+URmFHXzjdbgoV+T72+Mahn5qfJzenxyplmCyJEYRaB/30PlJRWC QHRbARRCLSDxBlWGgg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([213.142.97.127]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N33Ed-1tfqZf1CiT-00zRMB; Fri, 29 Nov 2024 16:53:58 +0100 Content-Language: en-US In-Reply-To: <87jzcn1af7.fsf@mail.linkov.net> X-Provags-ID: V03:K1:4e0s2dguPx4ArVO6ikx1rAWv6oA6eM7qJPUe/88cl9nFMiqIRhS 18sYzDyIxuCwu1re9338L40FhCHFClAMNTJ7YjUbPoudCpuU3xTOnIq4tm8hG+j0CtFWsHM Wr8yvWAufKMRd2shWXy+3T9eHWMo6yLNMYhyrJQ6MGc/8qlkgYauceJpVlyiaB8DEHkBh+o sxdPg1oZxehwXUhlMJclQ== UI-OutboundReport: notjunk:1;M01:P0:Lj8gRnUMw7U=;2mq05vq4vuWgj9coLvoLKPr4HWk zUYprzoAs1WuxgLcPoVRpF5aonmjTDROS2XlW7v2ut0Krm482CQ8PgNCMqthe+lI84Hes/yDq iDCCiIYiY81fwXK5PTacTZw5CbNDi0ssNXyUqRtjqy5RizCS1LMb4pwXGfTj7tJ4q2i2gZN8s ifE2t4+OG5xDMln94q/fVBowt4LbHbDSi5GAmycYE5Wt5apR56t4D9xUMQ0rwUMO9ihvOIvIe uvaZSsbjj+oDs0BQktS76RJ3y0Fgfg2szZCc6k6ri5+zC679MCTH00rUa61H1THn69weZkc9f OqtHhvT6HNmBM8i7LXpwBbY3jauGS+cTdDLUr/iSDRSzgFYrMrKZZr3cVr13OpDzvNdloR5LQ 0mQgEXwNs2TknRgHY6pAayT1MseMBSr/xt0474sd0wY7Q+MMM+stAwlnGAUV6TZKhx3pFxQ7J tvv9Zk4048Rv/QDp28YIRd+BGSQrGfah1tSSDIbEXFxLBJF/6rJzizCJYsQXa9aBKCsVUIjDt 9nsZgsG4G8+MXnU879H9OUjDJroCUfej/uVuph6uKipFS77Ou+bcrvhwQX0QWpFeUAwO/db6f VkZiaJKm3MDrj/jgq0ChQurF2SBYfqqOovbtuAPGcXMkvfJlGQ1sxg7FEJVcMUtraKgZsWNdM MjNY82aPHXeKFoIfm8VG+PypnfMLyMu958DZI3VKMLfrA1g2a7gSXyjDEIrAmKWr8QjqLJYKn n6xmwZQ6NWl2BVBON/Lh+zPXmXJTPZUnj0ejrBgKepxmzFQCF2lNDKpV8NhzjYqCSEaVSg1q 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:296096 Archived-At: > The drawback of reusing 'category' for other purposes is that > all current display-buffer calls that provide a category, > will set the window parameter 'category' unnecessarily. Correct. And affect the 'lru' behavior. > OTOH, the drawback of using a separate name is that many calls > will have to duplicate the same name as e.g. > > (display-buffer buffer '(nil (category . image-dired) > (parameter . image-dired))) We could make 'parameter' do both such that it has the matching behavior of 'category' and also adds a parameter. It's a question of describing it in a way people understand. >> - Allow for the value of the existing 'some-window' alist entry to be >> specified as a string like >> >> (pop-to-buffer buf '(nil (some-window . "image-dired"))) >> >> Slightly unnatural, but I see no harm with it. > > This makes such sense that if it has to find some window > then let it be the same some-window from previous calls. > > But it has the same problem as above that many calls should > duplicate the name > > (display-buffer buffer '(nil (category . image-dired) > (some-window . "image-dired"))) > Right. >> - Use a new alist entry, say "parameter" like >> >> (pop-to-buffer buf '(nil (parameter . image-dired))) >> >> More intuitive maybe. People would have to learn about it. > > An alternative name would be '(group . image-dired)' Still > the same problem as above: > > (display-buffer buffer '(nil (category . image-dired) > (group . image-dired))) Right. >> - Write a new action function 'display-buffer-use-window-with-parameter' >> and use it in conjunction with the previous as >> >> (pop-to-buffer >> buf '(display-buffer-use-window-with-parameter (parameter . image-dired))) >> >> Probably the most universal approach but people have to learn about a >> new action function + alist entry. > > This is the explicit and easy to understand. But too limiting. > display-buffer/pop-to-buffer calls should still use the nil action. The nil action doesn't come without its pitfalls either. If, as a caller, I use an explicit action, I at least live in the (possibly false) hope that my alist entry affects that function and only that function. With nil I have to study all action functions in order to understand whether my alist entry could have any effect and where. > So in conclusion it seems better to reuse 'category' in > display-buffer-use-some-window. But not to set the window parameter > 'category' in window--display-buffer unnecessarily. Instead > this window parameter could be set only in display-buffer-use-some-window > when failing to find a window with a category. I mean something like this > in display-buffer-use-some-window > > (if (get-window-with-category category 'visible nil not-this-window) > (use window with category) > ;; otherwise > (use lru window by default) > (set-window-parameter window 'category (cons category parameter))) And who would set up the 'category' parameter for the first window used by 'image-dired'? In my initial proposal, the presence of a 'category' parameter would mean to _always_ set the parameter for the window used. And I even would have the value of the parameter made a list like '(category . (tex-shell comint)) if that window would have been used for both. Another question: Would it make sense to have 'image-dired' do (display-buffer buf '(nil ((some-window . mru)))) in a first phase before embarking on a more complex solution? Or better (display-buffer buf '(nil ((some-window . mru) (inhibit-same-window . t)))) to make sure the selected window doesn't get used? martin