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, 05 Dec 2024 19:54:56 +0200 Organization: LINKOV.NET Message-ID: <87cyi6f2gb.fsf@mail.linkov.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18593"; 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 05 19:02:31 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 1tJGBI-0004cq-2h for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Dec 2024 19:02:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tJGAu-00078p-GV; Thu, 05 Dec 2024 13:02:04 -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 1tJGAs-000781-Fk for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2024 13:02: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 1tJGAs-0005Xq-6D for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2024 13:02: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=Kb217lPKbYCJ9uCAO/tqZm/gGkmDass4V4U1wf7K7JU=; b=C5NXbKiezuUJKkPaAIyXnW06NB8JMkKV8Rsa3AxZ7YL0dMMx+naJJyisMBrQz+z5scHd8G5zQhopbUdzLEEItBkusMBp/lTkYQ4gSgOUyCI0iGazU+NeLHLiRIMP+8EO/vsd6AhaDgQXTFaakky0V859LtNwjyJnoU/Qnye8aJn6293ul0QurR05IKw8aMX8MDhmXly+P08oxqSbN7kxxJiMruDDEEEa9YxVbIqLCRt/+/AlDKgM0SkDZEBf2o1QxxLkeKf/DaNBQseaO6hDCaQDJEOajMaB2Louai0xvcD+IHstwxKhsnyS6SLJ/qGof/i53K3N4nTEwZdfmE0eJw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tJGAr-0002O3-Tr for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2024 13:02:01 -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, 05 Dec 2024 18:02:01 +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.17334216969111 (code B ref 74246); Thu, 05 Dec 2024 18:02:01 +0000 Original-Received: (at 74246) by debbugs.gnu.org; 5 Dec 2024 18:01:36 +0000 Original-Received: from localhost ([127.0.0.1]:40645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJGAR-0002Ms-DZ for submit@debbugs.gnu.org; Thu, 05 Dec 2024 13:01:35 -0500 Original-Received: from relay5-d.mail.gandi.net ([217.70.183.197]:60317) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJGAO-0002MY-Kw for 74246@debbugs.gnu.org; Thu, 05 Dec 2024 13:01:33 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 8C90A1C0007; Thu, 5 Dec 2024 18:01:04 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Thu, 5 Dec 2024 10:23:40 +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:296477 Archived-At: >> In all customizations I relied on the assumption that the source buffer >> was current and its window was selected. And indeed I see the uses >> of '(eq window (selected-window))' in display-buffer functions. > > Let's assume a "source buffer" containing a list of objects (usually > links to files possibly enhanced with positions in them) a user might > want to display in a buffer. These files could be source files > containing definitions or compiler errors, images or simply all files in > a directory. A user might want to navigate that list to display a > "target buffer" showing the next or previous object with respect to the > current object of that list. Do we agree on that? Agree. > If the function for showing the next of previous object in the list is > `display-buffer', then if 'display-buffer-use-some-window' is called to > find a suitable window and there are several windows on the selected > frame, it would be nice if always the same window were chosen for > displaying the target buffer instead of using the lru window with the > consequence that the next object in the list is always shown in another > window. Hence some way to remember the last window chosen and use it > again in the next call would be a nice idea. The proposed way to do > that is by using a buffer-local variable. Do we agree on that as well? Agree. > DEFVAR_PER_BUFFER ("last-window", &BVAR (current_buffer, last_window), > Qnil, > doc: /* Last window showing a buffer via `display-buffer'. > This is the last window used by `display-buffer' for showing a buffer > invoked by a function with this buffer current. It is used by > `display-buffer-use-some-window' for displaying its buffer argument in > that window. */); > > 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? > Moreover, in the implementations proposed for setting it so far, > 'window--display-buffer' would set that variable locally in the buffer > of the window selected before calling 'display-buffer'. This implies > that the source buffer must appear in the selected window and would > preclude the use of a key binding that works even if the source buffer > is currently not displayed in any window. 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. > Obviously, we could also ask for the caller to pass the window to use in > a 'previous-window' or 'some-window' alist entry and set the window > previously used in some non-local variable pertinent to the caller. But > then why use a buffer-local variable in the first place? What am I > missing? 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. 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)