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, 6 Dec 2024 09:33:33 +0100 Message-ID: <6689d418-d028-40b8-b3d2-4ff12fe4283a@gmx.at> References: <868qtsmydz.fsf@gnu.org> <86a5dqm9gl.fsf@gnu.org> <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> 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="37707"; 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 Dec 06 09:34:14 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 1tJTmw-0009cH-Ej for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 06 Dec 2024 09:34:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tJTmn-0007nO-15; Fri, 06 Dec 2024 03:34: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 1tJTmk-0007me-VC for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2024 03:34: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 1tJTmk-0000Ae-MU for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2024 03:34: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=M3q/ngb7ZCY1tNfqOR2tiOCAw3WsTSonj55OSUrM6BU=; b=AR+FpHwhEuIfFGK0EB2kX0ZrU/5u66UPhn1B3t6/x5joJgpnjmdCn/Pt/7T0nw7jv+aSDjU8HmGgg3e7masaa2TIdAO4OkG/VrgGHrxJnMX30BuS8UhiHM/xvW8vy+jadChOLNioTMBM/s061bLYYoCwpSMhxH06C0H5UMQ4ZeSPbGhfW1d9TjKAeCOp3alwE8LCpKThH6Z0edzr9mce37qknRuEFCesSmuStTdAUyDrP9N8Bs/28gsIl3ndYupvXE70TY6iWLmXuCRxbBk5bwDowhHs6y06nyW6FJ0D0SMJrAgW7sg2gheeCF/dllYgPZuenfdCW+TFyorjCkUo3Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tJTmk-0003Hv-GK for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2024 03:34: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, 06 Dec 2024 08:34: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.173347402812608 (code B ref 74246); Fri, 06 Dec 2024 08:34:02 +0000 Original-Received: (at 74246) by debbugs.gnu.org; 6 Dec 2024 08:33:48 +0000 Original-Received: from localhost ([127.0.0.1]:41927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJTmW-0003HH-Ba for submit@debbugs.gnu.org; Fri, 06 Dec 2024 03:33:48 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:36857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJTmU-0003Gs-Ep for 74246@debbugs.gnu.org; Fri, 06 Dec 2024 03:33:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1733474017; x=1734078817; i=rudalics@gmx.at; bh=M3q/ngb7ZCY1tNfqOR2tiOCAw3WsTSonj55OSUrM6BU=; 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=DhbnJgqwS7oP4IlXEC7UUZkzXDeMp0Vadqq6KrV8xAb8xLDATSJz7sSdvJjTaSZr +AxyF3eCzlhLrPjhs188qnRSvQt31FXWSBzRBdtsJveB8KZfbU5AJoi2JF4rsiVV0 vIRKkIeOs8eGTLNT4c42niNWZfc/4M3kxbXhwBZEQk97+UnUA+rk2hG+UA4XhQnuJ bDIbwHXJhWXr5MTCxKHDWYMXr04ncGYYPc9U+/P+jxeHQjs1pjJnp6GNYV7fWyL/1 4hnRh04fXe/5JM68GqImscaxKXem/29axyr0oYzeJyGwK0KrJyHxCan3xHzGOMYMx uBWxZY+1OCxjacLdVg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([213.142.96.233]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MIdiZ-1tPCPE17o5-004jCY; Fri, 06 Dec 2024 09:33:37 +0100 Content-Language: en-US In-Reply-To: <87cyi6f2gb.fsf@mail.linkov.net> X-Provags-ID: V03:K1:9I1jSBQ4pM+Iks+JbPLKUlxJ5AOxyDlTYhzc9V/oVRXPdE//qI4 CJ6DGJqmSKFKR3OuFNgi1Qu8ncJy8Nhs7kGp5tVuvdgeVfsEX06W/Uh0oIYCzrzZ0eCiLBh hyLPMDwgIdeFUo9mwuPlrLC/wGu+RbI7h4ELKlAh//2E1+oy+vOfCbppQ/zuLVPwtYiDhjb NgY/Vh7bZeYwn5JAHbmjQ== UI-OutboundReport: notjunk:1;M01:P0:c45+cDUjDAE=;OKMejfU1iafxqw6RY409kOoHfNf ihRgf/QNtwcO363R6v2sM1BL3X/k6BFl/npucGTdHiLKnzbenlJSRrO61O0SRgpiF3QEdeaAo +ktMljefFEat2Y1c1T51H8E0pZamG4mY9t5utfFuABlyTA5eOLCztMaWvxaIdRAWSbl4xFMCg f4X3e9G9OgNN2vwutUnO/3YaboJK2gmBYxPTBZc4SDwLTIaZdwY7YNk47n3PpAmY3+rJP9FzY x7Wb6EUDipCIf1IMGIwqH+UEYDahZqCALC9/xM9aGXqzU5FqdYSXvZ2zDMDLyEuoauWf9MuZR edHkfsSVdmss/0FTyf1kwiFVyfgk2Su175tx6f8U/6kja+WIZ8xxliv3jkKP5U8cYxz6FAE1b mHStyXkBni2Sb0df8mEKP5YABh11lByRbV5286oXWNA5CSHi+eZKUYrnke3h4AICYWWndCIpN rih8BJ4rMkLkHjDB5JG64S6sgvCEfHlYhW86t+yp2v9TeEXosuSZof7W5NlBs7F9FCDOSl44M k+R8s5mf6lQ3j8Ey4VPyzzaH6yjTXggcgH+9BCis+IoJag2+7n8wno6ZiFwGWq4oaenf/jAp9 RrLzWAZZHVN6NciJzZuR9gu3MuNfyzwBRysRlGP5BEUIhbg0MpTvi29RYTtlO6rtIFbUnBVIm mnR2K/F7ZRky7YWE4lpr+0+XS+YbSGBH5I0OLh1MftlsdpcLvi2DjZiYBRDl2V4JuDkql5/LR Q3f5l6+ZntVQlKoTnwSPhxLG4M6UNX7x+AdOuTGggawwY7gDY8ufi0BnSlYBO0FT22BU39/H 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:296494 Archived-At: >> The second specification has the drawback that _any_ 'display-buffer' >> call that relies on 'display-buffer-use-some-window' may use that >> window. Just think of an error occurring during that call: The >> *backtrace* buffer will pop up in the window specified by that variable >> although it is by no means related to it. > > Indeed, this is not good. So only a category can ensure that > the same display-buffer call is used? You mean that is uses the same window? There cannot be such a guarantee. That window might have been (de-)selected, (temporarily) deleted, made dedicated and for any such reason may have become unsuitable for 'display-buffer'. In the course of years people have added more and more conditions why 'display-buffer' should avoid certain windows. Think of 'display-buffer-avoid-small-windows' - a global option that completely sidesteps the internal alist concept. > It's fine to set a buffer-local variable in the buffer where the user > types a key that displays the target buffer from another source buffer. > As long as the same buffer is used to get the value of this variable. I have no idea of a secure way to retrieve that buffer. > There are two goals: > > 1. replace the current lru with another default that reuses a previous window. > But not complicating all exiting display-buffer calls by requiring > each of them to set a buffer-local variable. When a standard variable > will be set, then it can be shared by different calls. Whatever we do: The buffer-local variable would have to be an option to fix the existing misbehavior of lru. And it should be used only in cases where 'display-buffer-reuse-window' can't find a suitable windows. 'image-dired' could safely use 'display-buffer-reuse-window' because it eventually displays its images always in the same buffer. It cannot do that right away in its present version because that one does ... (let ((buf (get-buffer image-dired-display-image-buffer)) (cur-win (selected-window))) (when buf (kill-buffer buf)) (when-let ((buf (find-file-noselect file nil t))) (pop-to-buffer buf) ... first pop up a buffer showing 'file' which means that 'display-buffer-reuse-window' usually won't find such a window ... (rename-buffer image-dired-display-image-buffer) ... and then renames that buffer to 'image-dired-display-image-buffer' - a buffer that 'display-buffer-reuse-window' would have found if it has been displayed at least once. Note that the present lru mischief doesn't happen for the first image displayed. It happens for successive image displays only, where 'image-dired-display-image-buffer' has been already displayed at least once. And note the 'kill-buffer' killing 'image-dired-display-image-buffer'. That one defies any attempt to set a buffer-local variable in that buffer. > 2. make user customization easy by using a special symbol like > '(some-window . reuse). But directly using the variable > is also fine, e.g. `(some-window . ,last-window) I would have to understand the semantics of 'reuse' first. What 'display-buffer' cannot handle currently is something like the 'image-dired' scenario above where the buffer would not be renamed. In that case it would be nice if the caller could set a 'category' or a 'some-window' alist entry and 'display-buffer' could use that to find a window with the same 'category' or 'some-window' value and display the buffer there. martin