GNU bug report logs - #74246
[PATCH] Reuse display windows in image-dired

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Morgan Smith <Morgan.J.Smith@HIDDEN>; Keywords: patch; dated Thu, 7 Nov 2024 20:25:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 14 Dec 2024 18:23:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 14 13:23:19 2024
Received: from localhost ([127.0.0.1]:48283 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tMWnO-00080M-IJ
	for submit <at> debbugs.gnu.org; Sat, 14 Dec 2024 13:23:19 -0500
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:52745)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tMWnM-000803-EM
 for 74246 <at> debbugs.gnu.org; Sat, 14 Dec 2024 13:23:16 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 93BF21BF204;
 Sat, 14 Dec 2024 18:22:47 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <e2b38a4e-e561-4941-9e06-0a4493368420@HIDDEN> (martin rudalics's
 message of "Fri, 13 Dec 2024 10:19:40 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
 <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
 <877c87o52j.fsf@HIDDEN>
 <eea8debd-654a-4c0b-ba1b-ce4bcc9142c3@HIDDEN>
 <87a5d19w42.fsf@HIDDEN>
 <2937c06c-631e-4fce-913d-f9a2fdc1df36@HIDDEN>
 <87ldwl2bgf.fsf@HIDDEN>
 <13844476-f2b0-4875-b77f-784013086044@HIDDEN>
 <87h678lp4g.fsf@HIDDEN>
 <e2b38a4e-e561-4941-9e06-0a4493368420@HIDDEN>
Date: Sat, 14 Dec 2024 20:19:40 +0200
Message-ID: <87a5cy5dqb.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> This should not be specific to packages.  It should be general to be usable
>> for any display-buffer call.
>
> Then for a *Compile-Log* buffer 'compile-goto-error' and 'next-error'
> would both try to use the same last window something they here currently
> don't.  And if clicking on a button in a *Help* buffer invokes
> 'display-buffer', it might use the same window for unrelated purposes.

Only if it was configured to use the same window.

Also the same window could be used by display-buffer-use-some-window
instead of lru.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 13 Dec 2024 09:19:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 13 04:19:57 2024
Received: from localhost ([127.0.0.1]:41577 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tM1q1-0002s8-8e
	for submit <at> debbugs.gnu.org; Fri, 13 Dec 2024 04:19:57 -0500
Received: from mout.gmx.net ([212.227.17.21]:50107)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tM1py-0002rr-9i
 for 74246 <at> debbugs.gnu.org; Fri, 13 Dec 2024 04:19:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1734081582; x=1734686382; i=rudalics@HIDDEN;
 bh=O0Mre1U2ZRPjDUh9wYL8StLolzWBFnyVxriXFUL97G0=;
 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=GLEgB6pdmbCHlGDasAJvv0w+6tS9bSDS8hz012jjWZuzF1O14k0wx0A/vPaW6ojL
 ytqRa+DB4oiXHfeWsXzSJEfP8fl54v/Pry/2Gmmks3Bb4RLGFB6okPKjf0esE3IP6
 XuutkB6KmsjMQOaiE3vSvFm8toP629bg6DNHqpBcfvaAEVaxqrD7k7AJFinQAl5/Y
 p2Rm1bGVIP//aEz//5ZrpyRalIdI7M8xOnCcG5QonSsQ13OSvoIFF9R5862oJ6bR7
 mnOxCqFZBa+tRnP6Ib6fF6hTZb7YBZAenHTfHogIz0ehAX7TkOaBL74yidpqiF5Je
 G8U560iu+hUhwsY2aQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.132]) by mail.gmx.net (mrgmx104
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MOiHf-1sy0fZ0BPb-00UzYN; Fri, 13
 Dec 2024 10:19:42 +0100
Message-ID: <e2b38a4e-e561-4941-9e06-0a4493368420@HIDDEN>
Date: Fri, 13 Dec 2024 10:19:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
 <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
 <877c87o52j.fsf@HIDDEN>
 <eea8debd-654a-4c0b-ba1b-ce4bcc9142c3@HIDDEN>
 <87a5d19w42.fsf@HIDDEN>
 <2937c06c-631e-4fce-913d-f9a2fdc1df36@HIDDEN>
 <87ldwl2bgf.fsf@HIDDEN>
 <13844476-f2b0-4875-b77f-784013086044@HIDDEN>
 <87h678lp4g.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87h678lp4g.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:kwxKam+f7VXZLRV0tFJm8YNCk929Db/F4fIwVOhBj/JYh2yeb7A
 qjnqXcCebEEygA6DFgfasePCllNDYVI7g46+Fago82TXghM/2ApWuMS3MYtaxXwZcb6R80q
 AogIDztuir2lof37Des1dJk4V++GNV28Mvbhp6nkDWufxzu9tHsAB1t1lrYm9s2A90CJzkq
 kRyzaf6509UktVnbDXfgg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:RWMaH4e/XzE=;lQOnd5W10O5k1gUBzCYgDYVHg+g
 RbVyH7aX7TLuk0KDbnRR8B4WZlwfrLG+xDlO9xfJjy93TEU/vHSVbf0tgkLprcUKgv1yygknQ
 tqGQDqnD0kPlQUWG1kKJAuEOgp/jEuCzRkgFzGYYCLMPgv95KUkyYHvacPEGmUqm4/bkqbMsT
 Iy/n/6BXp7sshZcNKjiqyP0vDXerhP0CZXhxNaBtgwB11OrnnJAc2WExQ+HBQzgy0F6oSJiX1
 3w+GM+LIHazak2ETDs6CuW+owJGeqmpUBCwRbR/7wLGcm3s5hnoWNGHUba/shuFcR8g5O8ivP
 eKDy8rxdF5ai/AaA4E/Fn+cXYK095Yf3AALkVqxzVvHgmfdD153071IV8d+eY+lG2Ht/Q2H14
 zCrC0X4vgRzl8jMMHQyw4JnsWWgpMqgMrEufSU00kG5pDhDDXgvV/MgGhchh6FSquiWTcgAbo
 W1ns2S9jxIlIBB/2+d9xgEIEy7VZfo64hL5K4qB6S1EMbn+1KvfJm+IiKvZ+aSzsyglvxR1kc
 XQ5TIFCjpjQwUq1g2SwD6nCwipZ+H88oOmhoCZwqNglA/aTSC+aQoUsciSZm2JKkUdv9fa8rh
 0cGqQOCTNKYLlKsHhKTbEsS237GR0o8tWahwbwULADg25M3dTTElaM80s39oX4ak53baSW4wh
 E3rdCo4hdXp6ep1invk6sUxKa676NaLDW1cENts/cpBa48FePI1vDSJ+3YJy9gNE1SnXy7kkC
 wILOT67WDxqLfmrgaQDOYiSkpjUn6gJ0Dkm3ycikai75s+lcoF2IkgvJg0uMWZwKRZ6CyZewW
 1dE+6gjxA0VYtluNQYPzE+x/miKk5cPm/fHYS9gWZg9sxKD0BdSUkhI4XmCpMbho5gx0ibJmV
 7ln+Mr9EekYraCOkNtpgEvVEl/9Lz4IyH6ba3ge07JGItOOkvRbRE1w+CLzT9ZpJcoX4KZRLe
 aaysbwv4fwzciu1El+7dWuZ9t7+bmA+6OpurVYYVyfHDbcfvYlvgMiguHMu2w/7urjLVAMPSp
 EQUv34rwjH/XRsB8jSxIedI/iib5vW2LG9gA2eLFB9g19HZad0xYqmMnHTVE07kMGr4tbyOGQ
 Zn6AuJZzjUZdmFumMzNJIfEkBcu+Qv
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > This should not be specific to packages.  It should be general to be usable
 > for any display-buffer call.

Then for a *Compile-Log* buffer 'compile-goto-error' and 'next-error'
would both try to use the same last window something they here currently
don't.  And if clicking on a button in a *Help* buffer invokes
'display-buffer', it might use the same window for unrelated purposes.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 12 Dec 2024 18:45:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 12 13:45:26 2024
Received: from localhost ([127.0.0.1]:40291 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tLoBi-0001w7-6v
	for submit <at> debbugs.gnu.org; Thu, 12 Dec 2024 13:45:26 -0500
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:55047)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tLoBa-0001rJ-6Z
 for 74246 <at> debbugs.gnu.org; Thu, 12 Dec 2024 13:45:24 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 7BA131BF207;
 Thu, 12 Dec 2024 18:44:47 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <13844476-f2b0-4875-b77f-784013086044@HIDDEN> (martin rudalics's
 message of "Thu, 12 Dec 2024 18:24:39 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
 <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
 <877c87o52j.fsf@HIDDEN>
 <eea8debd-654a-4c0b-ba1b-ce4bcc9142c3@HIDDEN>
 <87a5d19w42.fsf@HIDDEN>
 <2937c06c-631e-4fce-913d-f9a2fdc1df36@HIDDEN>
 <87ldwl2bgf.fsf@HIDDEN>
 <13844476-f2b0-4875-b77f-784013086044@HIDDEN>
Date: Thu, 12 Dec 2024 20:42:23 +0200
Message-ID: <87h678lp4g.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> Still too limited solution when the users can't store the last window
>> for other commands.  Better would be to add a new alist entry that
>> will force 'display-buffer' to remember the last window from any call:
>>
>>    (display-buffer buffer `((nil (category . compilation)
>>                                  (remember-last-window . t))))
>>
>> or by user customization of display-buffer-alist:
>>
>>    ((category . compilation)
>>     (nil (remember-last-window . t)))
>
> In that case the 'last-window' parameter maintained by 'display-buffer'
> would have to become a list of categories.  Then what about two grep
> operations running in parallel as you mention above: Would they share
> the same target window?

The only different things two grep operations don't share are their
source buffers.  Therefore need to save the last window in the buffer-local
variable in each grep buffer.  They can share the same target window
if the user wants.

>> And a function that stores/restores the last window could be customizable as well.
>> So the users could decide whether to save it in a buffer-local variable,
>
> ... buffer-local where - in the source or the target buffer?

In the source buffer.  But it should be possible to redefine the function
to use the target buffer, e.g.:

  (remember-last-window .
    (lambda (source-buffer target-buffer source-window target-window)
      (with-current-buffer target-buffer
        (setq-local last-window target-window))))

or

  (remember-last-window .
    (lambda (source-buffer target-buffer source-window target-window)
      (set-window-parameter source-window 'last-window target-window)))

>> or in the window parameter.  This option could be like 'xref-history-storage'
>> that provides the choice of 'xref-global-history' or 'xref-window-local-history':
>>
>>    ((category . compilation)
>>     (nil (remember-last-window . global)))
>>
>> or
>>
>>    ((category . compilation)
>>     (nil (remember-last-window . window-local)))
>>
>> or
>>
>>    ((category . compilation)
>>     (nil (remember-last-window . buffer-local)))
>
> Just think of describing this in the manual.

No problem.

> But I already see: We'll have to maintain a buffer-local variable, say
> 'xref-last-window' in the source buffer, have xref consult that variable
> and pass it as (last-window . ,xref-last-window) to 'display-buffer'.
> The value returned by 'display-buffer' would then become the new value
> of 'xref-last-window' in the source buffer.  Would that be OK with you?

This should not be specific to packages.  It should be general to be usable
for any display-buffer call.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 12 Dec 2024 17:24:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 12 12:24:57 2024
Received: from localhost ([127.0.0.1]:40142 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tLmvo-0005x9-HG
	for submit <at> debbugs.gnu.org; Thu, 12 Dec 2024 12:24:56 -0500
Received: from mout.gmx.net ([212.227.15.19]:55249)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tLmvj-0005wj-As
 for 74246 <at> debbugs.gnu.org; Thu, 12 Dec 2024 12:24:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1734024281; x=1734629081; i=rudalics@HIDDEN;
 bh=FH2DlbNr/AGEZf+VgKNLEy2F+TG358tr84y/FIzOc9A=;
 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=N5cGFTnW7kowzpXuJXGWbLA8ncd/9cDxBize5WjHVzc8YXFNSrMuh7cZVbjTUiBM
 qidaOxNKYfVq4RtwpQW1cdqXVXKPm+oTxLcN5/l3D0Izgl1RIBH43vrv3j4PG0H9c
 p2WVSLQMav5v6XNTSkNY8uI6QxUO2gbnmB1V4Km2yZIi1eU0AR8BbYXkvnuolU8F/
 Xile3EM8Ndb9wK39M5wvDbP1ePV+wy2TyUV+jwPkxD/hst4EO2mp4kPPFJghtUuS0
 rWD7aySA6AYtmLYv2vQ+zIP06q+HuHG+5t08h821++x+UMYDUmfLwhtfSHofaKgrc
 fHb+k4Y5D+MtnKzICw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.97.30]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MGyxN-1tPNpi14br-000TDM; Thu, 12
 Dec 2024 18:24:41 +0100
Message-ID: <13844476-f2b0-4875-b77f-784013086044@HIDDEN>
Date: Thu, 12 Dec 2024 18:24:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
 <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
 <877c87o52j.fsf@HIDDEN>
 <eea8debd-654a-4c0b-ba1b-ce4bcc9142c3@HIDDEN>
 <87a5d19w42.fsf@HIDDEN>
 <2937c06c-631e-4fce-913d-f9a2fdc1df36@HIDDEN>
 <87ldwl2bgf.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87ldwl2bgf.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:06z2v6IePNN99mVYn4YextRqyaqQIY6EOc17HMFDO2CIQhcPIHo
 WjQf+BDocePhoB+1kMDjJhIX9lH2hfgQ5Utiuz3lw1wtfIdJrwkFx2nbAPD5FidbFwBy1Pj
 4KqbvoyPx6n9PZ8Jjxwb7yeiC2rSfVSUv5CILssbhyxkl6zOQ+fU7wNTLF+LlKTJZ+uazTt
 FaHWozUgTlv0CdeaXwaSw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:dkkJAfKjYpo=;undpRhWzVYouOZoQGX3xZcRFq6S
 ccZzKNLhg97kya4m2sGw7rXvW4r91vKqMHxMZVGLAdg7J8ySKtaZHdzTJw5uhRP5C8kkB+dw2
 KUp8su2ujhLB7AGrHy0zE7Z2EjkuoteIwuFfOhTPYhLtJ33RKXuvKr3/pa+9C+xPYdFgDumEq
 Yp5L0VE/NPJ7mhVi3yBzqN50vq4DERiCwTEtcixmWeFSLD0EFk5vyLfcdAUq3mr0pqD4kxRCi
 vsG3n80umfRHzasE05Ws0maPFHrPWVPPNpNGaicVJY7TR5bqQqXkpk66+TJapTZaQs5qLqvSG
 xmQp2ncp1GZGC4wB0gS6/7qQk/c3Y2s1JM1RMyhCPxzimu9FhvT7xZ7jk1e3jt9cx+DLNtLAi
 KPfTbCl5NaTsOmwcBuoj+ETEaUW4TUeDxIZLMOSfJE18FTdK2WPWDdGaKhnpF8Dn92qIj169H
 SmHkmrCajO4tvoeE2CCUb3i5ngdBVhXVd+CrqoqNaZSCL72pfQobujoJ4seBeQD31ovzt9G+0
 rw9RnyrEtdqLBCLNRFv9dZKMyZKRm2YqWcGRp3/ZI9MNNF33cAREW0hYWiKxkHWcVJJBidvRE
 m3UrIZi5BzdiPKd8+/Fa+2Kv0TfiAPDqFcGSYWb9nUX0TxxdYueDUbTw74DI6W5xAl6HsjWEM
 FVgC28Qy7mx7njW7XBiTKYloV0B0u5wBO/Tjp/avzpEpd7BoTLMsoegIcoN2AKt67AMalC4HO
 ZDImbmjbeBuWJ13GSOWfieRGflrjIWYWJLOm0TqdV1AZ8NyVuaWH1i35qQaA8h5ZpKbdPBqZs
 vEnuMkx2R8A/KNtjDeeLsNGUnfLg6Ta9zHztPInOrJwO4FiG+VMebEbycv9sudVkzDsY/QpfW
 94SAyIw34lhxOQpA1QO6orOqUzyT1inolypIRSogHaiidvX6lA2Why+ryggSB7mZNQYhGoD4P
 hn1MvN+YhBwdXtcG6Z73Yw2+wFAYMrqL15zZ+lW4R28oTSo6sp9ZMJ802t6E2eEFq0BcjiBXr
 nFRXgwWl8t7A6ECrdNSlhFSMAIy6axWv61JBMmyQf7E98Elrt/5/C8vKSoAZNKmTkis0bq01i
 Ufi++HCoY2ObKfrGjUwCvj2c/EBwEK
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > Please not a global variable.  I often use many pairs of
 > source/target windows at the same time for different grep/xref
 > results.

I do that too.  Just that my "source window" is a sidebar of the target
window.

 > Still too limited solution when the users can't store the last window
 > for other commands.  Better would be to add a new alist entry that
 > will force 'display-buffer' to remember the last window from any call:
 >
 >    (display-buffer buffer `((nil (category . compilation)
 >                                  (remember-last-window . t))))
 >
 > or by user customization of display-buffer-alist:
 >
 >    ((category . compilation)
 >     (nil (remember-last-window . t)))

In that case the 'last-window' parameter maintained by 'display-buffer'
would have to become a list of categories.  Then what about two grep
operations running in parallel as you mention above: Would they share
the same target window?

 > And a function that stores/restores the last window could be customizable as well.
 > So the users could decide whether to save it in a buffer-local variable,

... buffer-local where - in the source or the target buffer?

 > or in the window parameter.  This option could be like 'xref-history-storage'
 > that provides the choice of 'xref-global-history' or 'xref-window-local-history':
 >
 >    ((category . compilation)
 >     (nil (remember-last-window . global)))
 >
 > or
 >
 >    ((category . compilation)
 >     (nil (remember-last-window . window-local)))
 >
 > or
 >
 >    ((category . compilation)
 >     (nil (remember-last-window . buffer-local)))

Just think of describing this in the manual.

But I already see: We'll have to maintain a buffer-local variable, say
'xref-last-window' in the source buffer, have xref consult that variable
and pass it as (last-window . ,xref-last-window) to 'display-buffer'.
The value returned by 'display-buffer' would then become the new value
of 'xref-last-window' in the source buffer.  Would that be OK with you?

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 12 Dec 2024 16:45:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 12 11:45:10 2024
Received: from localhost ([127.0.0.1]:40069 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tLmJJ-0003jx-Ce
	for submit <at> debbugs.gnu.org; Thu, 12 Dec 2024 11:45:09 -0500
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:50431)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tLmJH-0003eq-BZ
 for 74246 <at> debbugs.gnu.org; Thu, 12 Dec 2024 11:45:08 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id DEF1EC0002;
 Thu, 12 Dec 2024 16:44:57 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <2937c06c-631e-4fce-913d-f9a2fdc1df36@HIDDEN> (martin rudalics's
 message of "Thu, 12 Dec 2024 10:23:59 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
 <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
 <877c87o52j.fsf@HIDDEN>
 <eea8debd-654a-4c0b-ba1b-ce4bcc9142c3@HIDDEN>
 <87a5d19w42.fsf@HIDDEN>
 <2937c06c-631e-4fce-913d-f9a2fdc1df36@HIDDEN>
Date: Thu, 12 Dec 2024 18:40:16 +0200
Message-ID: <87ldwl2bgf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> grep/xref should remember that window in a buffer-local variable?
>
> As I'd envision it, xref would use a conceptually global variable called
> 'xref-target-window' or 'xref-last-window-used' and grep would do
> something similar.

Please not a global variable.  I often use many pairs of
source/target windows at the same time for different grep/xref results.

>>    (display-buffer buffer `((nil (category . grep) (previous-window . ,window))))
>>
>> could be customized to match a category and to use the previous window:
>>
>>    ((category . grep)
>>     (display-buffer-in-previous-window))
>
> Wouldn't that be overkill?  The user's customization would have no
> effect IIUC.  I'd say
>
>     (display-buffer buffer `((nil (category . grep) (some-window . ,window))))
>
> would be grep's proposal and a user's
>
>     ((category . grep)
>      (display-buffer-in-previous-window))
>
> would try to find a window that previously displayed the buffer first.

Still too limited solution when the users can't store the last window
for other commands.  Better would be to add a new alist entry that
will force 'display-buffer' to remember the last window from any call:

  (display-buffer buffer `((nil (category . compilation)
                                (remember-last-window . t))))

or by user customization of display-buffer-alist:

  ((category . compilation)
   (nil (remember-last-window . t)))

And a function that stores/restores the last window could be customizable as well.
So the users could decide whether to save it in a buffer-local variable,
or in the window parameter.  This option could be like 'xref-history-storage'
that provides the choice of 'xref-global-history' or 'xref-window-local-history':

  ((category . compilation)
   (nil (remember-last-window . global)))

or

  ((category . compilation)
   (nil (remember-last-window . window-local)))

or

  ((category . compilation)
   (nil (remember-last-window . buffer-local)))




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 12 Dec 2024 09:24:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 12 04:24:12 2024
Received: from localhost ([127.0.0.1]:37661 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tLfQZ-0003Qq-JO
	for submit <at> debbugs.gnu.org; Thu, 12 Dec 2024 04:24:11 -0500
Received: from mout.gmx.net ([212.227.15.15]:41819)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tLfQW-0003QO-Sx
 for 74246 <at> debbugs.gnu.org; Thu, 12 Dec 2024 04:24:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1733995440; x=1734600240; i=rudalics@HIDDEN;
 bh=PYoB46WVPkQdZ/7pSMc5/+hhk2pfH4xw2aBw/IHIskM=;
 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=MgRYvMNhgzifiQVRHRTHnESTxIqdB0ZXfVHnS0Y8X8o2hgl3aNgHm8UVotKf5+Mq
 US3ooyOJj+UmKi0rnLbWoMhq8xX1dcSEvcQtUS40akEWZMBVTVeTpnfdsHLLLchqg
 YgQC4J15hO2QQioje2o6zni+KjgKhHk+ha/Ss0QUyo9nK4PdSs9tepo9jPSvJi7Kc
 DYVzcHjoGsEB9Zd/SUJJZAbXjAkDp/vZg/TA+W+NMdARHOWbZqTDDS5yAyd3qqdG8
 W9Sq8V9Gq77lDLG5/Np1wljgwkitu2YmO8SmM3XiGFFP3p+nE9BxdCMFA3PxUO7ly
 ZQXAJ9+ASUccKqRdPQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.75]) by mail.gmx.net (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MQvCv-1t0a4F0Yz9-00Vi15; Thu, 12
 Dec 2024 10:24:00 +0100
Message-ID: <2937c06c-631e-4fce-913d-f9a2fdc1df36@HIDDEN>
Date: Thu, 12 Dec 2024 10:23:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
 <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
 <877c87o52j.fsf@HIDDEN>
 <eea8debd-654a-4c0b-ba1b-ce4bcc9142c3@HIDDEN>
 <87a5d19w42.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87a5d19w42.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:QcTKunTaxqyxXSugqmEW8qXF4YdcFAyS+XgvXGkXJsfzc1lHz+j
 8Bf8aHqoX+DSB+UVDmO9sAZpJkWm2qtWWJP9qWIOy/4Vcpe/CoGZ5eid/c52wwAQJgYmK7g
 L+qCLJHU4/2mUrc9e5X4TIN4UaEkULwpL+EkFgA7BffFisMe0HFR+b3HFTi0sD+W6rtft7C
 57zSxcmzDUsIr08cJQOJA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:c61dSFNQCiM=;pA96Amszs6Zm+Dpso/3dJU2v7CP
 kD7hf3qQBF0KylCwQ3KJB1nqk2vTs1NQ2/zGqwQcCs+SXMcXXPppD+cs1AqpWm8SRInxxLYvC
 vHSaXxaBY94EMMUB2xV7+OwyS3rR0HM8ee9VzKLgo/4rYujnK5c7dExGyD3vYjOLFsmUci3/x
 E2eCBshQWG4WaGqLNttMf9SePp2xfLc8xOqzQP/CnrmxVAGD510Dk19KO5uDk7hO9IR6DX9Ce
 wuqD0pBUwuUCuQ1pZpII5+C0UdZgILm5KN/bxTY6GvJXM0Z9EFvdveo4AjEuZLqGqGH9F44cB
 1BVtAkKl4SZCtrikhTpS5Xj3G2KHlT9gMToRBGAcD2Mv5Da5lwQNhQfqSG/yHcF6N29rkDuMB
 Hv+9NucyBJ4dT4Fnq2l44824NyS4yj8jhA4LlBXRuDqfdAxvQSh1f0fvbOI+XcvLaVfV20mUY
 /sR6XbiYnrzLsiapklgE5c56ryuk2LYeA3mQUKz7BZqt3ppFJehkFWh4WmHtCIFKBiFv6hQjv
 bgFmftJ+F8qC1sSdPSYWQmOmBFgTAZg+uD5AUcgsFkuR70Hv8rc3yTFlOZSHxGhdRW0q7vHgk
 YPKNflrUzwPGNQiYL3+gnmGg9MjMLFvVOoOV0z+SI3LvrgxKE1gPL3zHAtm4OJG6GgBviKe4a
 Gsltmllr+XXWpNUm+Bstn8n5iPkmZZhxy+DC7jD/FF9IHFLuRXs/RCWkmJz9embp5Zjs+jxEF
 Xg7WylLbmUjl6G3gmgXH9jThUrBtjOkUSQbCfu06vAluoDKKTyc1YjYViqDf1elCKpmH0dnKF
 qinwXPpNYhxPOIWozeSsYbSz48KFzYtMgXjyAPUZzs6m7EQkI0WAO9Z0g2/lMwsxwejky5KtB
 ONqMGlq0M9jU1k12F3OIj89bmOoU2n15sCN6/TM4UR/hoHqEr1dPIfPGW1CRO2bcrtNcyRQ3P
 N1fWTw70odjbyw48JJLbzNXAIypOYqtQTCxLIVQzUA9Vgy4ugPGSWodfQNEeDr676XE0q6RdB
 VuzlKa7Csx4LkzWYf09JRIHwy5jQE4UgoAj93dWAcm6B2Fizy8AktwJmPqCB7DrsqPSegdYQU
 5qPG25NIxIOg9ifs8ANUP+L6bbHx9k
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  >> By having grep do the following: >> >> - Issue a first
 request to display a buffer from that list, >> >> - remember the window used, 
 >> >> - set the local variable in the target buffer to the reme [...] 
 Content analysis details:   (2.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [212.227.15.15 listed in list.dnswl.org]
 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
 The query to Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243
 for more information.
 [212.227.15.15 listed in sa-accredit.habeas.com]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (rudalics[at]gmx.at)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
 query to Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243
 for more information.
 [212.227.15.15 listed in bl.score.senderscore.com]
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [212.95.5.75 listed in zen.spamhaus.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [212.227.15.15 listed in wl.mailspike.net]
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  >> By having grep do the following: >> >> - Issue a first
    request to display a buffer from that list, >> >> - remember the window used,
    >> >> - set the local variable in the target buffer to the reme [...] 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
                             The query to Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              for more information.
                             [212.227.15.15 listed in sa-accredit.habeas.com]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [212.95.5.75 listed in zen.spamhaus.org]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [212.227.15.15 listed in list.dnswl.org]
  0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
                             query to Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              for more information.
                             [212.227.15.15 listed in bl.score.senderscore.com]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [212.227.15.15 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (rudalics[at]gmx.at)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

 >> By having grep do the following:
 >>
 >> - Issue a first request to display a buffer from that list,
 >>
 >> - remember the window used,
 >>
 >> - set the local variable in the target buffer to the remembered value
 >>    before calling 'display-buffer' again.
 >
 > What if the user switches buffers in that window, but still wants
 > to continue visiting next buffers from grep in the same window?

It would have been the buffer-local value in the last target buffer
displayed.  But it's inconvenient and obviously fails if that target
buffer has been deleted in the meantime.  So it's not a good solution
either.  It's only advantage would have been that such a local variable
could have been shared between applications - grep and xref say - to
make sure one and the same buffer would always go to the same window.

 > grep/xref should remember that window in a buffer-local variable?

As I'd envision it, xref would use a conceptually global variable called
'xref-target-window' or 'xref-last-window-used' and grep would do
something similar.

 >> and propose it via a (some-window . ,window) alist entry in the next
 >> call together with 'display-buffer-use-some-window'?
 >
 > Such providing that window in the display-buffer call would be very nice
 > to do, e.g. with a more descriptive name like (previous-window . ,window).
 > This will make easier for users to customize by using different actions
 > that handle such alist entry: 'display-buffer-in-previous-window' or
 > 'display-buffer-use-some-window'.

No objections; just that the semantics of "previous-window" was so far a
"window that was showing that buffer" while here we would mean a "window
that was showing a buffer from the same caller".

 > Then a category will be continued to be used only for matching,
 > e.g. the call
 >
 >    (display-buffer buffer `((nil (category . grep) (previous-window . ,window))))
 >
 > could be customized to match a category and to use the previous window:
 >
 >    ((category . grep)
 >     (display-buffer-in-previous-window))

Wouldn't that be overkill?  The user's customization would have no
effect IIUC.  I'd say

     (display-buffer buffer `((nil (category . grep) (some-window . ,window))))

would be grep's proposal and a user's

     ((category . grep)
      (display-buffer-in-previous-window))

would try to find a window that previously displayed the buffer first.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 12 Dec 2024 07:55:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 12 02:55:07 2024
Received: from localhost ([127.0.0.1]:37466 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tLe2N-0005Gy-74
	for submit <at> debbugs.gnu.org; Thu, 12 Dec 2024 02:55:07 -0500
Received: from relay9-d.mail.gandi.net ([217.70.183.199]:46899)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tLe2L-0005DH-4U
 for 74246 <at> debbugs.gnu.org; Thu, 12 Dec 2024 02:55:05 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 37306FF808;
 Thu, 12 Dec 2024 07:54:35 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <eea8debd-654a-4c0b-ba1b-ce4bcc9142c3@HIDDEN> (martin rudalics's
 message of "Wed, 11 Dec 2024 10:38:21 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
 <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
 <877c87o52j.fsf@HIDDEN>
 <eea8debd-654a-4c0b-ba1b-ce4bcc9142c3@HIDDEN>
Date: Thu, 12 Dec 2024 09:52:13 +0200
Message-ID: <87a5d19w42.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> I still don't understand how a local variable in one target buffer could
>> help to display another buffer in the same window from grep/xref list.
>
> By having grep do the following:
>
> - Issue a first request to display a buffer from that list,
>
> - remember the window used,
>
> - set the local variable in the target buffer to the remembered value
>   before calling 'display-buffer' again.

What if the user switches buffers in that window, but still wants
to continue visiting next buffers from grep in the same window?

>>>>> pass the symbol of the function calling 'display-buffer' with some
>>>>> unique number identifying the nth call of 'display-buffer' within that
>>>>> function.  Everything else is guesswork.
>>>>
>>>> There is already such a symbol: 'category'.
>
> 'category' is much broader.
>
>>> But this one is already handled by 'buffer-match-p'.  We can't set it
>>> willy-nilly to some arbitrary value.  Otherwise, that function might
>>> match it in an unexpected way.
>>
>> 'display-buffer-reuse-category-window' could reuse the 'category' symbol.
>> Or '(some-window . reuse-category)'.
>
> Let me turn the table and ask you: Both grep/xref know very well which
> window was used for displaying the last match.  What speaks again to
> have them just remember that window after each call

grep/xref should remember that window in a buffer-local variable?

> and propose it via a (some-window . ,window) alist entry in the next
> call together with 'display-buffer-use-some-window'?

Such providing that window in the display-buffer call would be very nice
to do, e.g. with a more descriptive name like (previous-window . ,window).
This will make easier for users to customize by using different actions
that handle such alist entry: 'display-buffer-in-previous-window' or
'display-buffer-use-some-window'.

Then a category will be continued to be used only for matching,
e.g. the call

  (display-buffer buffer `((nil (category . grep) (previous-window . ,window))))

could be customized to match a category and to use the previous window:

  ((category . grep)
   (display-buffer-in-previous-window))

> I think the main advantage of such an
> approach is that grep/xref would be in complete control of a good
> proposal for such a window, something most users could hardly resist.

Agreed.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 11 Dec 2024 09:38:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 11 04:38:37 2024
Received: from localhost ([127.0.0.1]:32923 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tLJAu-00018G-RA
	for submit <at> debbugs.gnu.org; Wed, 11 Dec 2024 04:38:37 -0500
Received: from mout.gmx.net ([212.227.15.18]:60387)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tLJAs-00017k-GJ
 for 74246 <at> debbugs.gnu.org; Wed, 11 Dec 2024 04:38:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1733909902; x=1734514702; i=rudalics@HIDDEN;
 bh=iUlLdHjEENoy2RTXfb5U7yIwBu5uKuRIK8rmjMDLRX8=;
 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=KVGbI8h0dm7XkzEZPU/OAAaK3BcpOa0AByjO0soVFaX2q7UVFt1s0Ve0wRwZN6k2
 DlKQGXtr7/xyryjDxmLH9MZXd7E7k86sNXQdmsO2nIHEYHxu1unK4o3luVNP7L3ZA
 QSo1j6Ym8tEkqeKoVbFbPxpbktW+O4fl5pWzgY9oTFI7z+ubb5EYgCfsc68qdKqZP
 gM/ZQlcQssJB+XJQVIR1m8eXQk2kewuZAySm02h75ihFMKLNy5ntUl8P1SgcX/Gdv
 G9oA1TFWAe46E4gLJri9ZUwceup6Bgue63MPhSCdXvfv6fGQSt283cEKkTbebqM+p
 vmURcljWJFmvWls+Bg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.97.12]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MacSe-1tszEF3Uk6-00oblS; Wed, 11
 Dec 2024 10:38:21 +0100
Message-ID: <eea8debd-654a-4c0b-ba1b-ce4bcc9142c3@HIDDEN>
Date: Wed, 11 Dec 2024 10:38:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
 <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
 <877c87o52j.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <877c87o52j.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:kbfIi6a/e0a6HVauw7mnD8IHMcTq4eXCrFoRdFAZOyE/xJReuWI
 8J3Cfy0o3K7nh5U4lY+mJ9PGIem99vss1j1xGwNR9kU9CFaRRLtCq11fbvXo/mVqHuMrkEe
 nz6lGaS0PisIEXV3lRZxUnAOLFpQUb/Q+SjY4RzXB8LnWwOUmev1g7iCbxGH9lQArw3xNNj
 9Zfhqt4MnQKsYKgc1LKhw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:97TJMIrLQcg=;icTbISuHfZodrV53DQvRhqKxWEx
 VYB9yA6NK6vDO2UQ322/SbHOsmoE/Wb2eTLzjy6u7WeNrsYt/2aUNYh+5Gk+Y38L8DCoSbDRx
 6PGvKXt6BMQbjHcu6YVnI+STbvpMpy8ZGe9c0Dqk3cwVecjraGw1h2xXN2ARiLZr3LD7p1yjD
 Y2c0ilRUjWZ6kUPmYyYSULjoJZ8Ig0ETq153gGLZh3iJ0JDQLOfmLjqPDzaNFgmn/3S7Y+SHU
 7uQn1ar1lBeJgDfkBsQAiVK7W7vNASCHO6k0h0+7dRGrJ7J+bK6UcmtZZStONsd2QrTT82FM4
 ptCb1rhxVeuh3kjt40rR5I8w+5vLAbUlHZPf4OElXyE3B5edcSVtoZzpOOfkcpXq1Dya8kjJr
 WmNxH73LVFZoDN6/zQW0kD+zj7+lE9C8yyWaaf59DYZ7S3WtjZtvnaYrPDSBDs16/KlDGPP42
 +uHmwkntPbdfQ2t6AMknQMoulD6S8BFMsucdCyCKlHIt++xdUHykNnk22hQonhhgYbhbQf/GR
 fSeujJpZy3D4I+y+V8tb4+4+Q5rtS6QY4OuYNJk+4Xz34dfCx77ooSIAYpy4zMoU0OjfSbqtA
 Cu0p6OjD9PktoqRE6qHcm41PKo67usDr6/asOXCv6iTw39R9b+pYIFudWTQf9Iol02x7b0jtb
 W3TZHEAReqsWh7GUYFyaNmCYtWsJdfxmqex6O1VJGVkOUvP3A27iB1ejWTfHWh5e08V89kvDJ
 sj10qXStdV3o0CPlBd8c/QJlvBN/nWBwCsTymp/fpiSyy/hblkeLVahzN5al/G9EdAmO0oh5w
 MclOref6P5+r+82hRRbZGK9/uHSms/Qq+0KCjx+4REEQAL3nprURIQRVh+eMJl2crvgj09kTb
 LN3wRVGaWwabyk2O+u+CXGSo/9dk/sR4FW4Lk9SOeUo3PZfxhuJ8VwTRJRZ9eFj40OOuf5yrs
 YCS7jcCFaSXBqKsYF9OeRUNc1T2jfVbtKGE/nxYYZJ1RqLRzuT+8c1FBSWHg4+t1vGsyESUkC
 aHOc8b/1TGSWGorPrz+Lc8UHocHV4V2zPivbVdSrxjk7hqSbSbghKte8YpvH9JNsHHAxO9L45
 9CzMsye1l2onefVvfVv/AnNvI1QYRM
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > I still don't understand how a local variable in one target buffer could
 > help to display another buffer in the same window from grep/xref list.

By having grep do the following:

- Issue a first request to display a buffer from that list,

- remember the window used,

- set the local variable in the target buffer to the remembered value
   before calling 'display-buffer' again.

It could do that if it wanted to communicate the window to use in a
buffer local variable thus avoiding to pass an extra value via the
alist.

 >> Would you like that?  I think displaying *backtrace* in the same window
 >> is always a bad idea.
 >
 > Only when 'display-buffer-below-selected' fails that is extremely rare.

I assumed that the user had customized it.

 >>>> pass the symbol of the function calling 'display-buffer' with some
 >>>> unique number identifying the nth call of 'display-buffer' within that
 >>>> function.  Everything else is guesswork.
 >>>
 >>> There is already such a symbol: 'category'.

'category' is much broader.

 >> But this one is already handled by 'buffer-match-p'.  We can't set it
 >> willy-nilly to some arbitrary value.  Otherwise, that function might
 >> match it in an unexpected way.
 >
 > 'display-buffer-reuse-category-window' could reuse the 'category' symbol.
 > Or '(some-window . reuse-category)'.

Let me turn the table and ask you: Both grep/xref know very well which
window was used for displaying the last match.  What speaks again to
have them just remember that window after each call and propose it via a
(some-window . ,window) alist entry in the next call together with
'display-buffer-use-some-window'?  I think the main advantage of such an
approach is that grep/xref would be in complete control of a good
proposal for such a window, something most users could hardly resist.

 > Not either, but preferably the last used window.

Not preferably, IMHO.

 >> 'image-dired' _is_ different because it always uses the same buffer for
 >> showing images stored in different files.  I know of no other function
 >> doing that.  Do you?
 >
 > I don't remember any other function doing such non-standard things.

So IMHO we should exploit that fact in its 'display-buffer' call.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 10 Dec 2024 17:49:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 10 12:49:02 2024
Received: from localhost ([127.0.0.1]:59481 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tL4M2-00029k-As
	for submit <at> debbugs.gnu.org; Tue, 10 Dec 2024 12:49:02 -0500
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:38545)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tL4M1-00029B-25
 for 74246 <at> debbugs.gnu.org; Tue, 10 Dec 2024 12:49:01 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id BA8EAC0005;
 Tue, 10 Dec 2024 17:48:51 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN> (martin rudalics's
 message of "Tue, 10 Dec 2024 16:55:32 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
 <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
Date: Tue, 10 Dec 2024 19:30:28 +0200
Message-ID: <877c87o52j.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> What would be the safest approach to detect the same 'display-buffer' call?
>> A category?
>
> As I already mentioned: The calling function would have to reserve a
> separate alist entry for it.  In my initial proposal I had even a
> separate argument for that purpose.  Alternatively, one could reserve a
> local variable in the target buffer for that purpose ('display-buffer'
> would have to reset it).

I still don't understand how a local variable in one target buffer could
help to display another buffer in the same window from grep/xref list.

>>> Unless a user has customized it or 'display-buffer-below-selected' fails
>>> for some reason.
>>
>> Then displaying it by some-window in the same window instead of lru
>> looks as a nice thing to do.
>
> Would you like that?  I think displaying *backtrace* in the same window
> is always a bad idea.

Only when 'display-buffer-below-selected' fails that is extremely rare.

>>> As I said above this is not reliable.  The only reliable thing is to
>>> pass the symbol of the function calling 'display-buffer' with some
>>> unique number identifying the nth call of 'display-buffer' within that
>>> function.  Everything else is guesswork.
>>
>> There is already such a symbol: 'category'.
>
> But this one is already handled by 'buffer-match-p'.  We can't set it
> willy-nilly to some arbitrary value.  Otherwise, that function might
> match it in an unexpected way.

'display-buffer-reuse-category-window' could reuse the 'category' symbol.
Or '(some-window . reuse-category)'.

>>> If a user issues the command to display an image in a window that
>>> already shows an image and insists on using another window, an arbitrary
>>> other window can be chosen.  Users who want that just get the usual
>>> chaotic behavior lru provides.  They asked for it.
>>
>> The users might want to switch displaying to another window,
>> and continue displaying other images in the same other window.
>
> Yes.  But then either of the windows could be chosen by the next call
> (if that window still exists).

Not either, but preferably the last used window.

>>> With 'image-dired' it can be set in the image buffer because that buffer
>>> is always the same.
>>
>> This is an exception, not a general rule such as for navigating
>> grep/xref results.  I see no reason for image-dired be different
>> from grep/xref.
>
> 'image-dired' _is_ different because it always uses the same buffer for
> showing images stored in different files.  I know of no other function
> doing that.  Do you?

I don't remember any other function doing such non-standard things.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 10 Dec 2024 15:55:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 10 10:55:46 2024
Received: from localhost ([127.0.0.1]:59179 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tL2aQ-0000Qj-9W
	for submit <at> debbugs.gnu.org; Tue, 10 Dec 2024 10:55:46 -0500
Received: from mout.gmx.net ([212.227.17.22]:56833)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tL2aO-0000QI-1m
 for 74246 <at> debbugs.gnu.org; Tue, 10 Dec 2024 10:55:44 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1733846133; x=1734450933; i=rudalics@HIDDEN;
 bh=s1k6FvFnnjm7WDmYF5afEMbh6FfV53Ka2ezN7CNhm4I=;
 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=QGp+lJxVC1H+gSU7op1cMiNl72GbtVCvBFSvodBJtN3lsi30lDual/a/zhKBkBeK
 /BB/QYsK1rOqggWxkUtzXu+pz7y4YGDQjXWvaUhjfJ767VgeHAVKOgo9yD79gBCyB
 SdOZ7twEC6ZX9l2WYWSdHtkArpfGhYiSFhAHYXwmYVJ54+HXFgaL0wUA4/SPBuPOg
 Wq5POzxkubxlS7yGtD8NFfqaYn9mU4ber+uMTMVH8i39pdDE7aHlCBgcACN3iK1MM
 RjeKDfWNbafqyV66bocBD7vomUIg9COx2crQk7eI3aS8VkHt5c8IIO731AAjklywt
 Bifx4Hpl+QNLyrHrlQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.34]) by mail.gmx.net (mrgmx104
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N7i8Y-1thdvb01C6-00ynQS; Tue, 10
 Dec 2024 16:55:33 +0100
Message-ID: <24d8f9ec-788b-4bff-a67f-ccfbca1da725@HIDDEN>
Date: Tue, 10 Dec 2024 16:55:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN> <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
 <875xnsll9k.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <875xnsll9k.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:7RO2AG9JyAsq0L+S0uUQTxlNNEiWmHkNb9CdPSRwUbVjv6UHbnX
 t79B+82/NulzEyCFCbxyjxtervghzl/ZvVn4gYqvtReUX7Ju18MluyQx4o2L0TuC+eVjCen
 RdL1+if0/8QGep2x9OofP7ymw4moLMHt5POckycatcwMoiTXJ354PWygv3EpNs53z7/KSDY
 zy1X18TuwmcFoANl6GliQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:5m2FkdkYsqw=;oNAq4tS8Lby/GN0dYTV38WnXyjS
 L4RHuRqvd1w7H3eLXXK35gB2S8EsIk/cmHjtsT/LAm0km2VTXTvxLCMBPgOjUGlX6Htcheelv
 512FwIS4dB7+wf19AhERKb1GIsvemSCk32cjeeHyfhbcp/UzixcpMX4ygiCGYJxFBVEvpQjm3
 bZCeQksYou3aBjcv6VUdUbAgcKkrmv6xIVOnBnadfAh0WFwYbCJXie0O2YPNXzE2MKFb1DZo1
 4ppCGxe9PLPaW2Hod0C0CUCWBkkR7dhvGOWukKJGsKUfixve1NQJYnHo/5dtbVcJq7k7IE0k6
 j+y6jFj1bw3n0XG6Ti+L99zBSxBJPLP4qJcM/uSKLlE5wcZPMbhuKHCf+M179X2JRUm0Fm7i7
 vRr/eviILOp5b4ykEqLj7wujIJRqOeYnqB4viuD9QZzKJURpUukGpVD6CZO/8vZT4wR3kW6Is
 Wso8boH6nCzEyyITl8NbcuIdMCJnd+dSYsp87SVKmWfXMYL34vkwWphScmvGF7KhkjCnuvmeE
 80pYvdWpoc9uYV3Wbrxw/Mjf5llMmVuUq66Yprond6GuoFv67V2Xac5+AIKViBORGIMqSbR02
 +n7IMDZDcd18xgmE9Ryzm+3gjr8QpOkJpmXyvumkMHrO8jqfBdcFgd3HY68ZORIzi7YQ19FG5
 /NnTyBKvgQNb0rqr2JZPOFJc41orRD9SlIm9Dq5EBkU3ubC4+uQsIQPyVjXRrIS/M/ISkZbS9
 6Jj8+fJs1HRUsP4d1+7EP/04oaGT6oKSnP3RHa8nl6TYea3taelk7yvOVUGJwpARQR2QeLzNS
 BBUo3NyaJV42rlQOoQxOEyuFZIO01nrSYV/tzUIN/JU0IxQ88bwiI5AH7K+ftm5r0yF2UuCa+
 mo0oo10Yd0Pweynky1GRCQQqRZLZXcD7vPp+ug2Xon1NZmkP/mVarDVxkT2SkvTrnBXiVf15W
 oQWr90wWSPu//ZK2a5Oz6UbYPBNeF8gP4dQVbPhT6n8V4NDgfWbqDeeyZOgSkpB9bh9cUq0Lf
 Q1m+Y2z2buVWHxNoA+INTDKPrX8xNE38sPbdELQyzMneA8T3t0LW6AqJb0H/oI0fBh8+AVvwo
 /C2qyrkSpdIhpEU0rOh8B7sRIVbIy9
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > What would be the safest approach to detect the same 'display-buffer' call?
 > A category?

As I already mentioned: The calling function would have to reserve a
separate alist entry for it.  In my initial proposal I had even a
separate argument for that purpose.  Alternatively, one could reserve a
local variable in the target buffer for that purpose ('display-buffer'
would have to reset it).

 >> Unless a user has customized it or 'display-buffer-below-selected' fails
 >> for some reason.
 >
 > Then displaying it by some-window in the same window instead of lru
 > looks as a nice thing to do.

Would you like that?  I think displaying *backtrace* in the same window
is always a bad idea.

 >> As I said above this is not reliable.  The only reliable thing is to
 >> pass the symbol of the function calling 'display-buffer' with some
 >> unique number identifying the nth call of 'display-buffer' within that
 >> function.  Everything else is guesswork.
 >
 > There is already such a symbol: 'category'.

But this one is already handled by 'buffer-match-p'.  We can't set it
willy-nilly to some arbitrary value.  Otherwise, that function might
match it in an unexpected way.

 >> If a user issues the command to display an image in a window that
 >> already shows an image and insists on using another window, an arbitrary
 >> other window can be chosen.  Users who want that just get the usual
 >> chaotic behavior lru provides.  They asked for it.
 >
 > The users might want to switch displaying to another window,
 > and continue displaying other images in the same other window.

Yes.  But then either of the windows could be chosen by the next call
(if that window still exists).

 >> With 'image-dired' it can be set in the image buffer because that buffer
 >> is always the same.
 >
 > This is an exception, not a general rule such as for navigating
 > grep/xref results.  I see no reason for image-dired be different
 > from grep/xref.

'image-dired' _is_ different because it always uses the same buffer for
showing images stored in different files.  I know of no other function
doing that.  Do you?

martin





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 9 Dec 2024 19:19:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 09 14:19:50 2024
Received: from localhost ([127.0.0.1]:55675 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tKjIL-000836-0U
	for submit <at> debbugs.gnu.org; Mon, 09 Dec 2024 14:19:49 -0500
Received: from relay4-d.mail.gandi.net ([217.70.183.196]:56895)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tKjII-00082m-Gy
 for 74246 <at> debbugs.gnu.org; Mon, 09 Dec 2024 14:19:48 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id EF9D3E0006;
 Mon,  9 Dec 2024 19:19:37 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN> (martin rudalics's
 message of "Sun, 8 Dec 2024 17:55:17 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN> <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
 <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
Date: Mon, 09 Dec 2024 21:16:39 +0200
Message-ID: <875xnsll9k.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> I meant that only the same command (and therefore the same
>> display-buffer call) should reuse the same window.
>> This is why I checked for 'this-command' in the posted snippet.
>> But instead of associating with a command name an alternative approach
>> would be to use a category.
>
> One and the same command may issue an arbitrary number of
> 'display-buffer' calls.  Checking for 'this-command' may work for you in
> a specific context but is certainly not a safe approach for general use.

What would be the safest approach to detect the same 'display-buffer' call?
A category?

>> The *backtrace* buffer is not a problem because it uses own
>> display-buffer alist that overrides display-buffer-use-some-window.
>
> Unless a user has customized it or 'display-buffer-below-selected' fails
> for some reason.

Then displaying it by some-window in the same window instead of lru
looks as a nice thing to do.

>> display-buffer-use-some-window could recheck if the window is still suitable
>> for every use of the same command and display-buffer call.
>
> As I said above this is not reliable.  The only reliable thing is to
> pass the symbol of the function calling 'display-buffer' with some
> unique number identifying the nth call of 'display-buffer' within that
> function.  Everything else is guesswork.

There is already such a symbol: 'category'.

>>>> 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.
>>
>> It's always the current buffer, even if another buffer is used
>> as the source buffer.
>
> But the current buffer may vary continuously, it might even be the
> minibuffer if I issue the call from there.
>
>> What if the user wants to display an image buffer in another window?
>> Then 'display-buffer-reuse-window' can't be used.
>
> If a user issues the command to display an image in a window that
> already shows an image and insists on using another window, an arbitrary
> other window can be chosen.  Users who want that just get the usual
> chaotic behavior lru provides.  They asked for it.

The users might want to switch displaying to another window,
and continue displaying other images in the same other window.

>> A buffer-local variable should be set in the source buffer only,
>> not in the image buffer.
>
> With 'image-dired' it can be set in the image buffer because that buffer
> is always the same.

This is an exception, not a general rule such as for navigating
grep/xref results.  I see no reason for image-dired be different
from grep/xref.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 8 Dec 2024 16:55:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 08 11:55:34 2024
Received: from localhost ([127.0.0.1]:51521 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tKKZB-0003H9-Hb
	for submit <at> debbugs.gnu.org; Sun, 08 Dec 2024 11:55:33 -0500
Received: from mout.gmx.net ([212.227.17.20]:37209)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tKKZ8-0003Gq-8h
 for 74246 <at> debbugs.gnu.org; Sun, 08 Dec 2024 11:55:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1733676921; x=1734281721; i=rudalics@HIDDEN;
 bh=UHU7wt6StGa7mnkn8+jcZ9DBsBi6jX3jPdh71ERBRr0=;
 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=jty5N1Py+pSoB0vCHypJzi3qPVurGDwERjL3IGep73HJDAHZHhF0Owd4XPrTjhgo
 5JfLXbIdZ2mnOf4hMdUe037YWyucerDDvsk71M1Lf6Ml66cytAvYsbr5J8bLvWxnS
 8wBg5VP+v+DxyIT4pM4WW/o8ilFOQA2Qmd22HbNbZL41iL+a0lDrWXaIggmj7YrVP
 JbhyFV3R3Rs91F2ife3cgyQcbT6A0pz5X80i1ES+O/NLQEej73TTJMvoTrcMtkMqR
 xqU4dkGFSW18AsmDnl/aYYtLj13WeqDsXgQof7qnawvapSRT1uAwXtuzvXqyyb9Ov
 0wtRxRTG7jdrTU2CrQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.71]) by mail.gmx.net (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MgesG-1tq60T13hk-00gG8c; Sun, 08
 Dec 2024 17:55:21 +0100
Message-ID: <7a548d2f-144b-45e3-9558-8908a2a4a86b@HIDDEN>
Date: Sun, 8 Dec 2024 17:55:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
 <87ed2jwhm5.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87ed2jwhm5.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:fd32Q15BumBmsKhORLhy4qX/I8rSoBgxVBhzTmL9fWh9dJMMHhX
 AOV+Jhqlg8dbqJITK8u6pqlaaM5NBapGuy7A/Wvs7YlV+Ov/QHlqwOK1iG5ttNm3DuAwFqz
 sbb6aOXVM2jEBQHyrxpRp2cJ8SugRJhO1ac5ST3JsSOR0uLWPTvtIDU/OkbHt+g8zMXeMEG
 RRQ4Z/tAMX2fht9rEHfWQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:kOYlwa6L5DY=;qTslUaBbdIMplksJ5aS263NYUpq
 ZuvW6a68yUOtciO94ErtcbcBVVClFlrra53tEDxjJCrhSlSNJPf8YgnpVFzSL0Hx2mBvcCQzo
 owEYuOCVq8NB7CAy9FEXG33zH2qBDhn7zMVAeyDQUjgTVbHhGKKHY8X9X1G634fFiubV+IgW7
 38yPgsUchL/I8H1VGPFa25zwN/D8oZ2uGAzywGBs2mi5ulYyc+FQ9haGe5NCy9FSHW8uJBui5
 hyLOZroIXnBgcSyVWyn29NMq3oH3t7+BMiaoTf6JHjlFldrlEYooRMmrRqX2k1XktpPAnkaxw
 45wVCzcDcFOl/IQ9jjYRt0e+xQSdC+257a3B/xOw79DHW2ASE9Whyt2ql4vNFPF1F18u5EusI
 HbvYz/hbZ524FW+lZRCVOF1E5YMuexi6lg7VMTGFslNomNdPR237IPkhcUr9YTVY2lvUroUx3
 0jgdhJ11vcNj/1jMmS0YkkQxyv3RarRMC3826B0PP+XzhoBVdDDClWEeDxzce4alNSy91WlqH
 p7Mv/q6LeerWjngrR+8OJB83cNNYFmas515z8DI5yFEqlYSgQj0IPVY7XM+ZfSEfgS4yOQ3Ct
 4AyJQeuvq5J7GgZB4twhYo3njMWxlspj1xGMBCn0KvdkHTQP9snFm1xiGqu3OeKgJx4GbxxKb
 O3NwXyFB2BqeDyBLETZM5c1mnI8IQVvnX4RpfX5K/PlDt7rWw5oi1cESy7AaxE01DDyts3FKf
 F8tA9D5zzVxuWouWYu88NbUOQl00XMiEd2M++HQpbvvWtod08LwLaqSki+fPTskO4iq55qNyM
 QcqBAKiFDDImLNPYD/Xa3gvaYqt4LXjCc43voDSfcj0CfQNxkcKkQI0momoCXpO4f+g3EIQ1h
 6TQcHsZGy/mMLNGL+w7QHDQJIhnzYGBmcPMLamut8F4bBbtjwnJEqMQVvn12yOHXrj9deUqJq
 T59n/c86EfMS6agiVuNgtjoX1sDiaIzvve7cHQljabrK2EnX0MIGEyZlpH+zSX/ONvf9kjrZf
 tMdprO/lyFOttWDfjbdScDgbm5n2xEjjgu2xJWP7FbU1zF4kv6JFm9mKxFVCOETbUu8UMMdiW
 fEs7ZXUKJrGxTQxGZ5hf/rewLAYTHG
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > I meant that only the same command (and therefore the same
 > display-buffer call) should reuse the same window.
 > This is why I checked for 'this-command' in the posted snippet.
 > But instead of associating with a command name an alternative approach
 > would be to use a category.

One and the same command may issue an arbitrary number of
'display-buffer' calls.  Checking for 'this-command' may work for you in
a specific context but is certainly not a safe approach for general use.

 > The *backtrace* buffer is not a problem because it uses own
 > display-buffer alist that overrides display-buffer-use-some-window.

Unless a user has customized it or 'display-buffer-below-selected' fails
for some reason.

 > display-buffer-use-some-window could recheck if the window is still suitable
 > for every use of the same command and display-buffer call.

As I said above this is not reliable.  The only reliable thing is to
pass the symbol of the function calling 'display-buffer' with some
unique number identifying the nth call of 'display-buffer' within that
function.  Everything else is guesswork.

 >>> 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.
 >
 > It's always the current buffer, even if another buffer is used
 > as the source buffer.

But the current buffer may vary continuously, it might even be the
minibuffer if I issue the call from there.

 > What if the user wants to display an image buffer in another window?
 > Then 'display-buffer-reuse-window' can't be used.

If a user issues the command to display an image in a window that
already shows an image and insists on using another window, an arbitrary
other window can be chosen.  Users who want that just get the usual
chaotic behavior lru provides.  They asked for it.

 > A buffer-local variable should be set in the source buffer only,
 > not in the image buffer.

With 'image-dired' it can be set in the image buffer because that buffer
is always the same.

 > I have absolutely no problems with existing code
 > in 'image-dired-display-image' because of using:
 >
 > (setq display-buffer-base-action
 >        '(nil . ((some-window
 >                  . (lambda (_buffer alist)
 >                      (let ((last-window (buffer-local-value
 >                                          'display-buffer-last-window
 >                                          (window-buffer))))
 >                        (or (and (eq this-command (car last-window))
 >                                 (window-live-p (cdr last-window))
 >                                 (cdr last-window))
 >                            (get-mru-window nil nil t))))))))

Imagine users who once they displayed an image want it to fill their
frame entirely and want to use a key combination to display the next or
previous image there.  Web pages usually display a < on the left and a >
on the right to achieve that behavior.  Image viewers put similar icons
in a toolbar for that.  There is no visible source buffer or current
buffer around for that in Emacs.  All you have is the target buffer.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 7 Dec 2024 17:19:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 07 12:19:28 2024
Received: from localhost ([127.0.0.1]:48361 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tJySl-0000BO-PS
	for submit <at> debbugs.gnu.org; Sat, 07 Dec 2024 12:19:28 -0500
Received: from relay9-d.mail.gandi.net ([217.70.183.199]:56679)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tJySj-0000B8-Fl
 for 74246 <at> debbugs.gnu.org; Sat, 07 Dec 2024 12:19:26 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 27CBEFF804;
 Sat,  7 Dec 2024 17:18:56 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN> (martin rudalics's
 message of "Fri, 6 Dec 2024 09:33:33 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
 <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
Date: Sat, 07 Dec 2024 19:13:14 +0200
Message-ID: <87ed2jwhm5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>>> 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?

I meant that only the same command (and therefore the same
display-buffer call) should reuse the same window.
This is why I checked for 'this-command' in the posted snippet.
But instead of associating with a command name an alternative approach
would be to use a category.

The *backtrace* buffer is not a problem because it uses own
display-buffer alist that overrides display-buffer-use-some-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.

display-buffer-use-some-window could recheck if the window is still suitable
for every use of the same command and display-buffer call.

>> 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.

It's always the current buffer, even if another buffer is used
as the source 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 ...

What if the user wants to display an image buffer in another window?
Then 'display-buffer-reuse-window' can't be used.

>   (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.

A buffer-local variable should be set in the source buffer only,
not in the image 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.

I have absolutely no problems with existing code
in 'image-dired-display-image' because of using:

(setq display-buffer-base-action
      '(nil . ((some-window
                . (lambda (_buffer alist)
                    (let ((last-window (buffer-local-value
                                        'display-buffer-last-window
                                        (window-buffer))))
                      (or (and (eq this-command (car last-window))
                               (window-live-p (cdr last-window))
                               (cdr last-window))
                          (get-mru-window nil nil t))))))))




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 6 Dec 2024 08:33:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 06 03:33:48 2024
Received: from localhost ([127.0.0.1]:41927 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tJTmW-0003HH-Ba
	for submit <at> debbugs.gnu.org; Fri, 06 Dec 2024 03:33:48 -0500
Received: from mout.gmx.net ([212.227.15.15]:36857)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tJTmU-0003Gs-Ep
 for 74246 <at> 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@HIDDEN;
 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
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
Message-ID: <6689d418-d028-40b8-b3d2-4ff12fe4283a@HIDDEN>
Date: Fri, 6 Dec 2024 09:33:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
 <87cyi6f2gb.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87cyi6f2gb.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:9I1jSBQ4pM+Iks+JbPLKUlxJ5AOxyDlTYhzc9V/oVRXPdE//qI4
 CJ6DGJqmSKFKR3OuFNgi1Qu8ncJy8Nhs7kGp5tVuvdgeVfsEX06W/Uh0oIYCzrzZ0eCiLBh
 hyLPMDwgIdeFUo9mwuPlrLC/wGu+RbI7h4ELKlAh//2E1+oy+vOfCbppQ/zuLVPwtYiDhjb
 NgY/Vh7bZeYwn5JAHbmjQ==
X-Spam-Flag: NO
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/Hr
 MwgHdDMNlI9K5xNFqbYzHgcTKKAfS9ARnx6Q1LrnZXnpvFXbbjfjI2aMps457I7HmKYWFwBMO
 kONVt7b3+KPnUtFiSoWVV5121bWHL8wQr8H/+VVOtLrCNk/R+ppOdnT2Ka0FPVpwDh3e3r/bu
 dITidEqn6Lav4pd8JvLzKzqAQGYVrMJdUi8K5rr7xG3BHRbvVPcnRk2/x0Sr6SeBvq0YAI2XW
 ydCmCqwqG5yRZJ7d31O3gfYMjapXMf3mu2upWkhnXNhfhL4ap+tE7wdNkbkL2iXlHUAC2AqWg
 xfXaKvacyfPuE29zd6Wv+amA0lqolL
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 >> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 5 Dec 2024 18:01:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 05 13:01:35 2024
Received: from localhost ([127.0.0.1]:40645 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tJGAR-0002Ms-DZ
	for submit <at> debbugs.gnu.org; Thu, 05 Dec 2024 13:01:35 -0500
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:60317)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tJGAO-0002MY-Kw
 for 74246 <at> debbugs.gnu.org; Thu, 05 Dec 2024 13:01:33 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 8C90A1C0007;
 Thu,  5 Dec 2024 18:01:04 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN> (martin rudalics's
 message of "Thu, 5 Dec 2024 10:23:40 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
 <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
Date: Thu, 05 Dec 2024 19:54:56 +0200
Message-ID: <87cyi6f2gb.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> 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)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 5 Dec 2024 09:23:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 05 04:23:52 2024
Received: from localhost ([127.0.0.1]:38255 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tJ85P-0001pW-Rw
	for submit <at> debbugs.gnu.org; Thu, 05 Dec 2024 04:23:52 -0500
Received: from mout.gmx.net ([212.227.15.15]:47665)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tJ85N-0001pG-H5
 for 74246 <at> debbugs.gnu.org; Thu, 05 Dec 2024 04:23:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1733390621; x=1733995421; i=rudalics@HIDDEN;
 bh=73dHnvGiiRCagqFndfwll0toguDGtAMZSUrN/LNvFvI=;
 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=s8SZxaJsZJk05zsKVMO74ZzXQ4n93gQ10wgziOEfeX723iUACqiBKTuUkAoQ7F+M
 aR8mujQ/DfJBE3YWEkMJuxpVO2LcTNDlnwVoZ/zZUPxmLolZVNfinNbIKDoD9xebD
 nNv5xT3Lx/vQEAWGftBnDos0ytcZPA5usuMYhFxpFt5kwyv5jMThISpCjTaFT5gkP
 dTBZ5os4LhLfm4NZrPAWQNFdqvv1HSHXhmCCOdNImSAkTXR8FGhy5Dtis+mlt0VGg
 V76Q+Q1IJ2DBHGZcFdbNgjwkZcJ78RnrErJdW10A+GYPOmfvdIQ7d1VyGXyegRULI
 SRBcTGTmhb3i8+yPDg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.97.121]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M42nS-1tJ85F0v0S-00Dsxj; Thu, 05
 Dec 2024 10:23:41 +0100
Message-ID: <b43f5cba-572e-4eaa-8359-a31ac8ca0e55@HIDDEN>
Date: Thu, 5 Dec 2024 10:23:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
 <87ikrzjrj1.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87ikrzjrj1.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:UmlUJFh6/RjPS2JqLiCZiCCYlyXHyrfbLAd4EruK4zum/x9T96C
 tNvbYr0xVPtnL+WVzvSS5IebCkEOWFhvg+5KMIV7r7YLR+kw4oXXmoG0CsNkapsY75JTh+r
 1yzX7cPfrkqR3furQllOS42Iln1/urEWu4nbct2hM/PNu2nJiC3Nio2y2VZSLT/yMbJlVzj
 chFsyZOO/tfFtzeVgTjWA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:4rv+Q5ixPow=;+WlEXZiEiOP24rtatPvlA6O2niF
 ngTjWeRsbPFOuHBx0XRE5iM3eT1nXlmXwNosmhrHVHgiWTCuycsbA0c7LjQBWaHE56xPslFgY
 qdlZgNupz+cn2rBo5xlPGG3bbWWUU7uJkYpi3ZVORTmOFS0X8abkX9ZIiw8I/Yaaes0OupzVT
 Y4lsGTcRKMjGR28KZjtozUrnEpNLMLiSkbMBwpINC+NzPUx5PQSV/DBGMavuO9Q9PT7U79qPJ
 IGANUDxhwNZUht9UvaqZYl4V5b/j93mZRkVHFLgKnzoN7HFgXMqAFSOeSVuYbFwi1NV9ywqnA
 pSWg9UdyNoK0F9ktR1hlxeoMlAHmwCr1ACKJ341XHLCyezapJ3crr77PfT+y1AVB01+nL8FmS
 qxw4PaFkqSW6XRfJhmWFRNzQSBZDJvu8VsOut9No7qu2y0nYA1GbgPxNJ7bWlUrjEYkNObvMc
 KQTn+3H6TS50nBo2F8q5YYLcC+g2WHcivAAIvmJKPBiOGWayz6Cse4G2fnyVd1GvLEEyHsIzN
 y0zqQPISEoBhvHjdDCQw+9GVh6M2Q/hFoe/0OHmrYVEsdD4/slCQA4kZX413V/ONubba9H+TP
 fVVsktIXpny/a5zkmFR7R2IOillW2Mx96Q0NyNf9+aAvsbIGxXDcUAhwDbjblBaA54xgQXRRS
 YEU1i+zWnJ4UcE95hAYFpYUf5d0SV9PQTFj26CnjtUQ2hDadCZ2Y84oZrby0PwfSU7qgVFrER
 QIlo7+zwhHP07V4HZFWrqFul09AUYCbw7YdFH514rNvSwhwOXKDdwR/a3UXmxMh0FM9MAhYkn
 DT7zqmNuwhKy9/9vv+Nbhlqgjqe9j0rLsu1R+UtmoEV5VEMdmUAnyoXapMlqwUsQelgE6luMY
 XIDVkTkkShd+yRz7FQ7+u2awpCVFBwcKksHT9+nTu1oivZum1rYuuqj7q92CUmU79qWm5QScM
 moWg3H6Tr7IyvaoXPVwieGL9sfcKMifwTjZFd9MgGz65JQ4NZy2w5wTvbHAumlAqxyuMuv3hP
 ET5OXFgSiXRDNI/OO3bAA2csR0nqm07ztr80JrixCanlnapNI0BOVCKUDldnQZyzMMJKzDxT8
 iEZRZ5pGY1is+8vxF0pLvw5nGs6iEV
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > 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?

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?

Then let's store the last window chosen in a buffer-local variable say
'last-window'.  This can be either done in the target buffer as

   DEFVAR_PER_BUFFER ("last-window", &BVAR (current_buffer, last_window),
		     Qnil,
		     doc: /* Last window showing this buffer via `display-buffer'..
This is the last window used by `display-buffer' for showing this buffer.
It is used by `display-buffer-use-some-window' for displaying this
buffer in that window.  */);

or in the source buffer as

   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 first specification has the following two drawbacks.  The caller of
'display-buffer' would have to initialize it in a target buffer that has
not been shown before to the window that has previously shown an element
of the list.  Also, it's somehow redundant since 'window-prev-buffers'
called on all windows could find that window as well if the target
buffer has already been displayed anywhere.

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.

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.

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?

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 4 Dec 2024 17:33:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 04 12:33:04 2024
Received: from localhost ([127.0.0.1]:36658 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tItFH-0005Vh-VN
	for submit <at> debbugs.gnu.org; Wed, 04 Dec 2024 12:33:04 -0500
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:36035)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tItFF-0005Ug-Gt
 for 74246 <at> debbugs.gnu.org; Wed, 04 Dec 2024 12:33:01 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 8ADCE1C0007;
 Wed,  4 Dec 2024 17:32:34 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN> (martin rudalics's
 message of "Wed, 4 Dec 2024 08:59:59 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
 <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
Date: Wed, 04 Dec 2024 19:18:27 +0200
Message-ID: <87ikrzjrj1.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> Here is how I do this in the snippet I posted 3 days ago:
>>
>> (setq display-buffer-base-action
>>        '(nil . ((some-window
>>                  . (lambda (_buffer alist)
>>                      (let ((last-window (buffer-local-value
>>                                          'display-buffer-last-window
>>                                          (window-buffer))))
>
> This would imply that
>
> - the window showing the buffer from where to read the value of
>   'display-buffer-last-window' must be selected at the time
>   'display-buffer' is called,
>
> - as a rule, 'display-buffer' cannot set the buffer-local value of
>   'display-buffer-last-window' in the window it uses for showing the
>   buffer.
>
> Both implications seem harmful to me.

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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 4 Dec 2024 08:00:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 04 03:00:14 2024
Received: from localhost ([127.0.0.1]:34140 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tIkIw-00023x-8x
	for submit <at> debbugs.gnu.org; Wed, 04 Dec 2024 03:00:14 -0500
Received: from mout.gmx.net ([212.227.17.20]:35481)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tIkIt-000207-Ha
 for 74246 <at> debbugs.gnu.org; Wed, 04 Dec 2024 03:00:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1733299201; x=1733904001; i=rudalics@HIDDEN;
 bh=vgTz912Qjj8gRHhOXUI11yTSNIMx/FWO2msYbQ5GMZc=;
 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=GjM0U/OqV2TDosxzvbduqx7zNNmlI9paCli9c5b0hwOCli+JT0c6ByJdLossicvM
 V8qnVQiiM7dmCdl1O0YFGwhG9lJdFfYzulMLtORD+q0j+t2C3eoRxMNBXt8Fpt7JD
 pHjgXrgxVKvU617zi71qGLGoL42yrkYcvPwnh2YpLEEH0h22odXrzPzBEy4CfRsYM
 x45lbXPRmCBw6Rxmx7JLibffE7qyc3GZ2zrb7g2+T47FvonRV38Kf95Jn7eOQFxXN
 5HH5TSAsXxDzqquCwsm3thienvZSdeJfJFvqqIXEzXzZQlim1G2pei44n6NoWlqow
 N1WnBFGS7UmG8mJ8Bw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.8.217]) by mail.gmx.net (mrgmx104
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MBUqF-1tVh8w0mA3-000CvR; Wed, 04
 Dec 2024 09:00:01 +0100
Message-ID: <90c5f5d6-37f3-41a6-be7c-903e6d0359ac@HIDDEN>
Date: Wed, 4 Dec 2024 08:59:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
 <87plm8addt.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87plm8addt.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:JKWg3UAjp7Kfp/ha+opsNHemp8u9LIE5Lu3zINwInWXBWY2+etS
 0pqOxwQL/u1P2EytOCSzcz1lxLECtFV3joh6niiLOcM3EbbWacm1XVscbxoitKRBCF+ZXrS
 CfpWzIs72p1LI//MR7FKqEgzutGTpdkF6LRLZ0FcoBlW4ig/IqqK0lhU5toqMPiiJLwBdvS
 8lxKNepAiUqdS+tA6xeeg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:0WV83wshEM0=;xGVi/Z/qTItVPTWoCVPDNJzAlP2
 7OUqB3sLuJkTBgyjTkeNd/rXs+7s985imS/4bK9Bp1vUeiVqmJyX44DRDM7nlUjMNNF6X2G0Z
 uR9qgTjsXkTGv45doJ3s4pISzzcY9BgppSVcGvq8z1UMIHVslWariIY334g+L36huU4z8slXh
 CQ+E1f12xhlWwDDKWpDe42AgtCiLr6QPFjAtnsCY2Ojk301Tj/zozN9o/JxpA9TNjSMxhijxs
 nXD+oMJlcsc5K0Ob83rP9N4th4iKljKDe8wgIAxR5jgDbAHZndEe68Z4klLXqGlJL/NBKAOO4
 K7m5T8HLrHjEZRtRYTXOVSVKYnbLAR9+vvawHB/qKDHMIbWsZWs2eUcfB5PLBzkxSypD6n6r6
 3T7C1mvgTap35eWwi3K8bvHEQBzf9k2KpsrHtH+6Ahf5aY8tWNSI7BP6gGsZF3p3XUH6Pq/rK
 u3JMqARvGnsL3orkRP4H5bEH7AJNeI7BmAeFIDZVcRayG5wYEOXehnaZxfZwyJHf7XzhC9aoy
 w2uPGIbeDWvkG6V+NN7NIGfAZQxEr61zMp4+PcDU7Mu06H5ezuL+A/vjjQE/k6jKGPzlLH/UZ
 78+Xt6wRAhOibZND7YPggmiVGgHR5KCXe1l/sN6/Rx58Muol04oB+FxFpqraa6JZHLmvJJLH8
 o/0+1ZrZAIMfG0XDUHplxabCANvZvdkIJFnA1eRW5jZNtsqLwNqN0VR1BlBR7iHcu/p7g4G94
 cyEbiqLD+NYKhYhwsTZicKry0r2Os2s58IneUbaqj0y6WOx6oeh1t9oqbIygbqtxLcuZezA2O
 BmO4AhKdTjme8UzibZ7DhSm4YtPN7TzItHU8egwjsnB7iBC8xCZ5DF8Qia/L5n9puUNob47Bf
 G9mA85hkaSscCVfNPl/eKpiZffXimlDHxfKsua6XPkKOYmMSHQzJIRm8rYTBQ/qG0JX6gDJ/R
 nqzTzHOKMuKSApJg3TcvGgYAwUdlFZ0QYCmjeIhuaftmd2Kxvq/eZY0npHYj3hOam42s6zEPI
 V6Uyvb5jRFurnLYoxViO0co/rw+vJXvF5MTc5kRtIFKcOla6f9v6EZN5wvNuCItbUafQh0QBr
 pYzSZJgHO0JjJTYsQAVqWNszbf1cDi
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > Here is how I do this in the snippet I posted 3 days ago:
 >
 > (setq display-buffer-base-action
 >        '(nil . ((some-window
 >                  . (lambda (_buffer alist)
 >                      (let ((last-window (buffer-local-value
 >                                          'display-buffer-last-window
 >                                          (window-buffer))))

This would imply that

- the window showing the buffer from where to read the value of
   'display-buffer-last-window' must be selected at the time
   'display-buffer' is called,

- as a rule, 'display-buffer' cannot set the buffer-local value of
   'display-buffer-last-window' in the window it uses for showing the
   buffer.

Both implications seem harmful to me.

martin





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 3 Dec 2024 17:25:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 03 12:25:06 2024
Received: from localhost ([127.0.0.1]:32780 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tIWe2-0001gb-1U
	for submit <at> debbugs.gnu.org; Tue, 03 Dec 2024 12:25:06 -0500
Received: from relay2-d.mail.gandi.net ([217.70.183.194]:50357)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tIWdy-0001e5-8R
 for 74246 <at> debbugs.gnu.org; Tue, 03 Dec 2024 12:25:04 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 9162D40007;
 Tue,  3 Dec 2024 17:24:34 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN> (martin rudalics's
 message of "Tue, 3 Dec 2024 09:25:24 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
 <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
Date: Tue, 03 Dec 2024 19:24:14 +0200
Message-ID: <87plm8addt.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> It kills the target buffer, not the source buffer?
>> The idea was to set a buffer-local variable in the source buffer.
>
> But you want to display the target buffer.  How would 'display-buffer'
> find the buffer-local value of the source buffer?

Here is how I do this in the snippet I posted 3 days ago:

(setq display-buffer-base-action
      '(nil . ((some-window
                . (lambda (_buffer alist)
                    (let ((last-window (buffer-local-value
                                        'display-buffer-last-window
                                        (window-buffer))))




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 3 Dec 2024 08:25:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 03 03:25:38 2024
Received: from localhost ([127.0.0.1]:58210 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tIODy-0008Uz-1F
	for submit <at> debbugs.gnu.org; Tue, 03 Dec 2024 03:25:38 -0500
Received: from mout.gmx.net ([212.227.17.21]:48365)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tIODv-0008UZ-UP
 for 74246 <at> debbugs.gnu.org; Tue, 03 Dec 2024 03:25:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1733214325; x=1733819125; i=rudalics@HIDDEN;
 bh=z9nsAvnlqj0Ivgx9+awXsExFsKx+awKihBND7Yo5PI8=;
 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=cvgkCpWUOOpyDMrMPIANgMba962j282eY2y3T8z7nMfnn0K6eQ0EZApE+r6JdCCM
 fIm6Z3+VIl/Pc6lgw+++qKTdi+0O4YI795ILyCd4urTVfWt2TGZFC7MMA5IdI4J47
 wpfXeTJBRh2AhdYeA+Nuzvg6W0bHEVv0SjhRSuxsqdk1iazacMQgXx9JlI9rAnVVn
 BXKqT85QoSc47eN8Cl5d91Vhvp2BNv37YRJyvwbkR3HW3SCvHS8Y3JR8XBoRdV/uJ
 EcMsmT/vkPvHR4C+j3W53aNn4xUKjLJX7OvELz+vz4MnsETntzHpU7/BKXxJU3aqj
 AkY+9oBlyOA+Y43whA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.51]) by mail.gmx.net (mrgmx104
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MWzjt-1tC3bQ2v2f-00NoEX; Tue, 03
 Dec 2024 09:25:25 +0100
Message-ID: <8cd0088f-1beb-4871-a06c-17f8cfb23e29@HIDDEN>
Date: Tue, 3 Dec 2024 09:25:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
 <871pypb43g.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <871pypb43g.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:Fme9SCVJoWZVkuG7AFTw0r/rY/DjBWwlsdJAcVlnvaeMgEjcjXQ
 val2GltpsF7kHF8v6lAGbfRCZqLiCZlcmXXTUlASQHrnDTqR+BCy/+5EcnRZI6Yh6Sxv4ru
 3HiZ3hAKaZYRUEEYmjILBcHfs20AczmUIZovbsYL5UlpgOCDn7LV/HYFzPovqu7pdfVSBx6
 0AhaVr/lR9kQwkazkLrCw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:sAr8Z8lsHh0=;L2VV0VZ6dTfTF6BzZE31Pq5odi1
 8G+rio3EX9L0Qu9J9DMiLVvtSdwBD1x+PWHXpL2mpuGKG1qcCFzko5xua5K8nG1e7C4mCvWkW
 yl7eX1ry7HKQToPsDLb33fTF69HT47vCL24wutUcT3DlXLuis1ZNksl0jIa7zieKrI6Z1lKna
 v0TQdKQGoGHS5uFf12u1oNpV9EW4Sr7mIDQ9tOzlJl2LuDWpBkNRxvKSJZsBrmq4WqhRFW0ME
 Q+x/V5zPWISlsBuaUbSGybcLaOfZnPrNbtIQssYE4bMx1FWPkcquqTfmfDo6qEwzEofLOZwQp
 ui4uatk+7A2lHzOE3CT9xpgpjXXF3nPTSKmuRH/dbKig8CcCkR7hoeg/+MU+Qn0far/c/eF2o
 KTOQdWGX/bq5XptC/J0OoSyzdOssEqvz55coTlDdACgdukGGsi+/3tqvdAn2zrQYizGBDBi8s
 ErsAO8tSYClwOZxFFqkCY+03J+3UX6j9N/C+Q+GTtt3y1sE6S+5Rq4CVzHuc3jzLyrbwwKp7f
 T1BpQ87C+FRu/M2E3amBQc08pkPlEd6hGOCwscYWbJ6V8XT1QePtXyNYaSjyGKYJDus/Rsetz
 0sL9TPjSgFdEhkpKaPbDPxwS/1e1ecRRRiRUHVp7Yw+UYOS1fRlRmLey4S2ABbpydf2uQP6QK
 MSmSW0PpJCd4uWWG/9aM7nEvFpVBC9CNtnpJV71j74IzZxDenEX4VgGKNTH7nIrSdP9blFtXQ
 rMdv278Qu0jBswnViYNCDSlO3ylj4zRiDREEn2kjkbUepg5DOaOXXNbX5gb9pr3BH2/qt/vU8
 pGTYG1k9q1LbyiVs040ItQpaOO/KIQFmW72mHzEwNhMoSyghgnRdgKGvP0WXFSficgrJNNDCF
 7tKElWrsE8LkTVEIbr+pNG9rmOl/v6Al/Uo7hlmixNc8frq7tQ1k+wzGE40Ui8Cf/0PV4n4i5
 CuXdJxxGcz30dGNvM96du19wZT+3laccgLWFOwMpGXCpWsT6I9WtUmQR1OFwLKyY0HpdEuELD
 in/rKG3h3093Ry/aWovSLwZW+j6QL2MxSPhrZa+TqThJbCFEbhlQn+ek0c8bzhwhpmB4U/ByM
 T9HQvfxg8i2utwW6ma8wG/wq1N5x1U
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > It kills the target buffer, not the source buffer?
 > The idea was to set a buffer-local variable in the source buffer.

But you want to display the target buffer.  How would 'display-buffer'
find the buffer-local value of the source buffer?

 > Or some more meaningful value e.g. (some-window . reuse)

Yes.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 3 Dec 2024 07:48:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 03 02:48:24 2024
Received: from localhost ([127.0.0.1]:58085 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tINdw-0006YJ-0W
	for submit <at> debbugs.gnu.org; Tue, 03 Dec 2024 02:48:24 -0500
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:50285)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tINdu-0006Y2-5K
 for 74246 <at> debbugs.gnu.org; Tue, 03 Dec 2024 02:48:22 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 6A3151C0006;
 Tue,  3 Dec 2024 07:47:55 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN> (martin rudalics's
 message of "Mon, 2 Dec 2024 12:22:05 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
 <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
Date: Tue, 03 Dec 2024 09:47:15 +0200
Message-ID: <871pypb43g.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> Please explain why 'display-buffer-last-window' wouldn't help
>> for 'image-dired'?  IIUC, 'image-dired' uses one source buffer
>> that could use the buffer-local variable to remember the last
>> window it used to display an image buffer.
>
> Hmm...  Currently 'image-dired-display-image' 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)
>       (rename-buffer image-dired-display-image-buffer)
>
> so it kills that buffer and its local variables are gone.

It kills the target buffer, not the source buffer?
The idea was to set a buffer-local variable in the source buffer.

> Otherwise, you're right.  The question is now whether
>
> - 'display-buffer-use-some-window' should use the buffer-local value of
>   'display-buffer-last-window' autonomously, or
>
> - get it via a (some-window . display-buffer-last-window) alist entry.
>
> And obviously whether 'display-buffer' should set the value of
> 'display-buffer-last-window' itself or leave that to the caller.
>
> Maybe something like (some-window . t) could be used to incite
> 'display-buffer-use-some-window' to go for the buffer-local value of
> that variable and 'window--display-buffer' to set it.

Or some more meaningful value e.g. (some-window . reuse)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 2 Dec 2024 11:22:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 02 06:22:19 2024
Received: from localhost ([127.0.0.1]:54440 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tI4VP-0001mp-A2
	for submit <at> debbugs.gnu.org; Mon, 02 Dec 2024 06:22:19 -0500
Received: from mout.gmx.net ([212.227.17.20]:45185)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tI4VM-0001mX-Dd
 for 74246 <at> debbugs.gnu.org; Mon, 02 Dec 2024 06:22:17 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1733138526; x=1733743326; i=rudalics@HIDDEN;
 bh=DZOrKE4n4EMdvf9VvaxQ0dBPHA6SZA+N0S6FCsBZ5rA=;
 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=UeiPR64eKmzeG2mz6rtE8yOCD+99lenffsmglLGK098+S8PapDwKcv3iJkETygpN
 Q6BMWErgo2jPAxV6/JC10fVzXnhd3FOTEfnKvgdryoBufAK2gtkFzReYRNlJlMHpO
 0kxzsy7n0Hhq7nLIzlJuVt7lXLloeL2BCXNHvkNA0v+m4fDr/CG6xTjxbiQstaUx0
 mm9M0LkXw8sXIntw878c5p7A1FD+DBzZdNSLb/H76FDBD/3MInQMD3Kb5fXX5uC0j
 ztxW3+HFVz2eSyhavAUfuaysjQzWKMOFq+ciYoJetOqpfOgh3nDjV8B+PNvbWIa8T
 D9vGmSmgEsm5xIIrmw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.101]) by mail.gmx.net (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MLzBp-1t0GdT2klt-00Ip6w; Mon, 02
 Dec 2024 12:22:06 +0100
Message-ID: <3a5afa37-0ea1-4183-a563-ecc3067818c2@HIDDEN>
Date: Mon, 2 Dec 2024 12:22:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
 <87ldwyil8q.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87ldwyil8q.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:JskBfnWUq8YHSYn8emel3TZq5GsFBR9q2osnh/FFD5E3woqygPQ
 kUzHLYzjH6IUfu7I1I86Gz76ERTTZlZok3fyahIio+vTlU1MZVb/ouDRgDGun9ryMxl1rEy
 9AmJKiS+wo1HqLvnS1ZCYRgUAUlzHV0hfVxd0cCTsb2Vv0Wv8YbA2vsKoNVH0yKVC/akddX
 sqBrPIISx8QWkeMXfvOJg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:AU3emBABfxY=;eNqH3p6E8/ZKfH+vbIVvF4rZThv
 LO7M1e4J2ljjKv1+teilxGdDCuLv4ijDVc9Fc38C9PSjxz0B36WFBDIcMKLSDwN1TVJF7oBmS
 UDaJ4OBQaS3FnWaLiCYQtzfKK+04XCCXvSOk33dkG7qEjfkpembY1C/yv8bDpM8hHHwJbPaQf
 D4qQr0yjb+oNcd7Mx4DJF6g8mUtDoPzsBON1zqmK2CMgJn6G7Fk4+HPBmtlEnvKrG9RfH4yIN
 5vt7pND6aLi+EPJl4UFTtzk9iW9TlZohSOYnZlixrsPJ/4XbMraE8xozt+ZLTzKJZY0uhb/8e
 5aUJxUuJp2fg+LIF3j1U+PnObjufeZI8jF15A1Sq7wnJXwghXpzNT79o/2KOPFoeoGX61O/h1
 iVQi88trQF0CH6qjF5Atn4KtnnnsGA5CQiwdRhU2leWcYwIfn50M944E7tcNCTeRU0bZCTfly
 Xl/hoQKGCLUAh+WDDovvPjTWz38gXKo4RHNwI/mUc3lVRXWbDGe5w+GDCz1Q5R7Wn/AdIZSJD
 8l8UZpEyBrI8djc3rnn1Qnz2PGxLa78glMhGXu4wa6AJfacmV2jJ65w3APOaJhAwf0TeovveU
 b2ZseVHDbsu+Ll1/o+Fwugozv9ImoQ3teQs7AgSX0REUxbWVNwRmMZkQvQixuUZE0U06hyVsG
 BhxJ0JTRleUMnZMcfhSCaAW+i3Ls59L70XdQN+tFOQyzYTbM1r5KxYo8o8LLkvF6oqYLCscd1
 sxQnHrefRslxOb2K3Uf5UGPqNY2UoonZruJ8hBf1gHIWBhmae/ieopraVga9Y9Nxqz1cF8eS8
 nywdf3Jx4H7HfJ6y/V9fWGD0kvrIAEETmUPjK9L2MEIwUSgB7MLOkqqZNG/EV1+f+ICCHqG6R
 acrQM2RxuPBRn29Y+DFuqLSWd6+89JtMOBIgDt+xYsiVUeAenGWbZC5aN//QqT2tEYOP3oDp6
 rr3JcTtCc4vItpzfpuwKmZM6WMDmN0r4SakXmmTJMQwU5JHH5Lpy/WHxk0tPU0Hd1OphmklGI
 KzsN4dCt02ueYfBLqkpX4aHnjP/iDFKgP/rnRP6PCxzyub4O6pJBuD9oCey8at2+5UcbomStZ
 1fO/kzdaeqfuiG3ttyYdN/9mOWRBCI
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > Please explain why 'display-buffer-last-window' wouldn't help
 > for 'image-dired'?  IIUC, 'image-dired' uses one source buffer
 > that could use the buffer-local variable to remember the last
 > window it used to display an image buffer.

Hmm...  Currently 'image-dired-display-image' 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)
       (rename-buffer image-dired-display-image-buffer)

so it kills that buffer and its local variables are gone.  Hence we have
another motivation to use 'find-file-noselect-1' directly (or maybe
something like

(defun find-file-noselect-in-buffer (filename buffer &optional nowarn rawfile truename)
   "Visit file FILENAME in live buffer BUFFER.
Replace the contents of BUFFER with the contents of file FILENAME and
make BUFFER visiting file FILENAME.

The file FILENAME must not be visited by another buffer.  BUFFER must
not have been be modified.  Optional arguments NOWARN and RAWFILE are as
for `find-file-noselect'."
   (setq filename
	(abbreviate-file-name
	 (expand-file-name filename)))
   (let* ((truename (abbreviate-file-name (file-truename filename)))
	 (attributes (file-attributes truename))
	 (number (file-attribute-file-identifier attributes)))
     (cond
      ((find-buffer-visiting filename)
       (error "A buffer is already visting %s" filename))
      ((not (buffer-live-p buffer))
       (error "%s is not a live buffer" buffer))
      ((buffer-modified-p buffer)
       (error "Buffer %s has been modified" buffer)))

     (find-file-noselect-1 buffer filename nowarn rawfile truename number)))

to avoid that people overwrite a modified buffer).

Otherwise, you're right.  The question is now whether

- 'display-buffer-use-some-window' should use the buffer-local value of
   'display-buffer-last-window' autonomously, or

- get it via a (some-window . display-buffer-last-window) alist entry.

And obviously whether 'display-buffer' should set the value of
'display-buffer-last-window' itself or leave that to the caller.

Maybe something like (some-window . t) could be used to incite
'display-buffer-use-some-window' to go for the buffer-local value of
that variable and 'window--display-buffer' to set it.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 2 Dec 2024 07:44:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 02 02:44:12 2024
Received: from localhost ([127.0.0.1]:54120 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tI16K-0007UU-Hn
	for submit <at> debbugs.gnu.org; Mon, 02 Dec 2024 02:44:12 -0500
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:60489)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tI16J-0007U6-CK
 for 74246 <at> debbugs.gnu.org; Mon, 02 Dec 2024 02:44:11 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 95A141C000A;
 Mon,  2 Dec 2024 07:44:04 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN> (martin rudalics's
 message of "Sun, 1 Dec 2024 09:46:18 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
 <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
Date: Mon, 02 Dec 2024 09:42:45 +0200
Message-ID: <87ldwyil8q.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> I agree with the need to set the window parameter always.
>> For example, I often use commands that override the default action
>> with e.g. windmove-display-up/down, etc.  Therefore needed
>> to add an advice that remembers the last window in the
>> buffer-local variable:
>>
>> (defvar-local display-buffer-last-window nil)
>
> Let's define it via DEFVAR_PER_BUFFER in buffer.c and have
> 'window--display-buffer' always set it.
> 'display-buffer-use-some-window' then could use it either by default or
> if it finds a 'some-window' entry whose cdr is nil or t or whatever we
> want.
>
>> However, I still like your proposal to use a category instead of lru,
>> that could be used here later as well.
>
> With 'image-dired' 'display-buffer-last-window' wouldn't help.  But
> 'image-dired' could define a mode-local variable, say
> 'image-dired-last-window', and propose that as 'some-window'.  We could
> make 'some-window-method' accept a live window for that purpose.

Please explain why 'display-buffer-last-window' wouldn't help
for 'image-dired'?  IIUC, 'image-dired' uses one source buffer
that could use the buffer-local variable to remember the last
window it used to display an image buffer.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 1 Dec 2024 08:46:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 01 03:46:37 2024
Received: from localhost ([127.0.0.1]:50238 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tHfbA-0003Zt-Pn
	for submit <at> debbugs.gnu.org; Sun, 01 Dec 2024 03:46:37 -0500
Received: from mout.gmx.net ([212.227.15.19]:55197)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tHfb6-0003ZL-Uh
 for 74246 <at> debbugs.gnu.org; Sun, 01 Dec 2024 03:46:35 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1733042779; x=1733647579; i=rudalics@HIDDEN;
 bh=cskvYv61mZSIGHj0UVMovf4XgGAqiS5dakCgkUaIKN0=;
 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=Ovm5FCr0Z1sha9kQg0VOJ0NDv61CiucSYpuCtB7jhKkhZAfKlyhn2YzKZ43dGH3y
 t5XWWDD7WC5qNi6Z1GHP01BdOv799Un3opHTBKB8fqTNIDTwI84xDHQ/+3tJxIJVF
 UH9qll7+V669ymBL6PyDLrbCfHMkQHksCS7MQ/tg/fJG80jL0M48uIAOCT24g453P
 XaFLrOTSsvTeZQ5RX8fDXZ4gbdFwqpRq6EaTV3ucEynRAUItywPCxngmmJS5PVwhs
 Yir7wLoSjuKwEdx0PGnaZMB8U9rSdQchYRXoZVN/8B+MmXvW/w3HbiQBFqftqm8aP
 Zx42SwBNQW0pG5W5DA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.58]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M5fMe-1tKRXd2UuY-00BAAQ; Sun, 01
 Dec 2024 09:46:19 +0100
Message-ID: <a36e24d6-91c9-407b-b961-5f0b8683600e@HIDDEN>
Date: Sun, 1 Dec 2024 09:46:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
 <87y1108u9k.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87y1108u9k.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:af5JGX6YmgKKAbjJ4eBtcWp8CEcbDX0pBkOGadqqGPMLfRDtW11
 1PvD/4U5MsNWrziLvkS5M0tLHG3Fphe8DZg0nk18rIHe7EQ3x1Z483HY9yoWpc/9xpzxcq1
 xRxF62QGvHaGYTsaVX3T+2tWrPVU8s8L0sQVFp26ShrPOaIPbZ3ZYCODR0FssoW08zgprKi
 TULg1V7VRbZSCSgFdfsXQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:8JvrPkVF/rY=;O6rJTSt7JqUjGZx+IB/wUGchbdk
 zK0NmIeov3VI3UfK6rPVzmU/7OuzzajMlF6jEPoQZmmpE9/u2NTaWnZQrU0/8hoZ3MAM72umo
 IpUVk13TwH6iGSJQUO5l1O1+OTgKa7hDVLUJqTedwiarAGfMTVqeu+4l/QGYbQClJzdEIkhja
 Q88wGTWVychXQnhFpnDDuJe1QCxAxBTi04ntBvclHQwxGRVA+8LamQimkZISEDE2vIyeNoafe
 +2X9LJ1wolnwaS2Wq7xkPjYYUFvdYRiwAPPq+98FtaNJZpci+EppXB7hoh+vqJCJ0zhxa3uvq
 CEk/jEfMT1qlO1HXhGC9qMCrMBbWHojsI/LD5+gPWWDsWgQEYYFo1x40Yvq51gbrNQ0Bk7c5T
 4efWhmk3LbTcSqYOEI6RLgc9lhvi1SG58wTR47yBYCPuh5KHMQDn3DX2kKpjUieCrYaXmKiH/
 mFS/7XYLNZ5Nm7pB+KsjTne+TTFvk898pHEP2tV84S880xbGedmqNVccfVFTIlTbF5YVDXKdx
 T725n08GZnMPBgibrJeNC5sn36ND2brWjHLKKE62EZLFeDbem8IaPxWDaSKYE8YOSkDOYR6gv
 7RTp4zm3YCxTC7ekH0DDdOhsga1BWvnAPDKLGv4dEK6VX1YI97zn0TBjsNJuOYOnnhVvYiHxU
 tLyS6/vNNKOpMLXF43pWVy65ojTAj7yy4b3ukgEB+EEpCXAe0suWIn47X8eI5AT613Ba2SYeq
 I2uLM38R7iErL5vQPuVlxMmWBh0W+H/rHFdzj6gXKrtJiH4mfa4u8uSacJBqd19qt2lz0JjC5
 V/rDlOQ3oHLvXvYtbMIuTzYYJLUzRWcwjTOELvrj1RrIEfOxFsGbyKNwFJy2oUVe+jkCN0he3
 IzXtkI/OlWHiqBdBfvfWivTl4IeOi9dBt7AJ+ocu/0RXKTG0RsEfVOv5Hh+icsESaGF+aBlxh
 qMKA1A0mjGKWpkwgpiqTMSv7f4iVQTW36sD7IjOfH+Rzy/zU3C1WgWph1L+RUW6FDw4LsmjSi
 50D0jMT8vV3PYJedd6wJJ75FSCX7YZMbcveXPIN9q5SrwnHe0C8Hxs4+JZNhAod0pwppktd0m
 z/0e7EtjEqfmkCQ4/Y4jzlvS2eTjLY
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > I agree with the need to set the window parameter always.
 > For example, I often use commands that override the default action
 > with e.g. windmove-display-up/down, etc.  Therefore needed
 > to add an advice that remembers the last window in the
 > buffer-local variable:
 >
 > (defvar-local display-buffer-last-window nil)

Let's define it via DEFVAR_PER_BUFFER in buffer.c and have
'window--display-buffer' always set it.
'display-buffer-use-some-window' then could use it either by default or
if it finds a 'some-window' entry whose cdr is nil or t or whatever we
want.

 > This uses the buffer-local variable in the original buffer
 > because IIUC setting a window parameter like in your patch
 > can create such a situation that more than one window
 > will have the same window parameter.

Which is no harm per se.  But it should be possible to exploit it
somehow.

 >> 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?
 >
 > This looks like the best immediate solution.

Morgan, can you try that?

 > However, I still like your proposal to use a category instead of lru,
 > that could be used here later as well.

With 'image-dired' 'display-buffer-last-window' wouldn't help.  But
'image-dired' could define a mode-local variable, say
'image-dired-last-window', and propose that as 'some-window'.  We could
make 'some-window-method' accept a live window for that purpose.

 > But get-mru-window already prevents selecting the selected window
 > by the arg NOT-SELECTED of get-mru-window in display-buffer-use-some-window:
 >
 >    ((eq some-window-method 'mru)
 >     (get-mru-window nil nil t))
 >                             =

I thought so but was too lazy to countercheck.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 30 Nov 2024 18:18:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 30 13:18:17 2024
Received: from localhost ([127.0.0.1]:48962 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tHS2r-0000P8-6E
	for submit <at> debbugs.gnu.org; Sat, 30 Nov 2024 13:18:17 -0500
Received: from relay4-d.mail.gandi.net ([217.70.183.196]:38671)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tHS2p-0000Om-2u
 for 74246 <at> debbugs.gnu.org; Sat, 30 Nov 2024 13:18:15 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id BB37DE0004;
 Sat, 30 Nov 2024 18:18:07 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN> (martin rudalics's
 message of "Fri, 29 Nov 2024 16:53:56 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
 <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
Date: Sat, 30 Nov 2024 20:03:27 +0200
Message-ID: <87y1108u9k.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> 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.

I agree with the need to set the window parameter always.
For example, I often use commands that override the default action
with e.g. windmove-display-up/down, etc.  Therefore needed
to add an advice that remembers the last window in the
buffer-local variable:

(defvar-local display-buffer-last-window nil)

(define-advice display-buffer-record-window (:after (type window buffer) set-last-window)
  (with-current-buffer (window-buffer)
    ;; TODO: maybe later turn cons into alist ((COMMAND1 . WINDOW1) (COMMAND2 . WINDOW2))
    (setq-local display-buffer-last-window (cons this-command window))))

(setq display-buffer-base-action
      '(nil . ((some-window
                . (lambda (_buffer alist)
                    (let ((last-window (buffer-local-value
                                        'display-buffer-last-window
                                        (window-buffer))))
                      (or (and (eq this-command (car last-window))
                               (window-live-p (cdr last-window))
                               (cdr last-window))
                          (get-mru-window nil nil t))))))))

This uses the buffer-local variable in the original buffer
because IIUC setting a window parameter like in your patch
can create such a situation that more than one window
will have the same window parameter.  But need to keep
only one unique parameter in the last window that displayed
the buffer.

> 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?

This looks like the best immediate solution.

However, I still like your proposal to use a category instead of lru,
that could be used here later as well.

> Or better
>
> (display-buffer
>   buf '(nil ((some-window . mru) (inhibit-same-window . t))))
>
> to make sure the selected window doesn't get used?

But get-mru-window already prevents selecting the selected window
by the arg NOT-SELECTED of get-mru-window in display-buffer-use-some-window:

  ((eq some-window-method 'mru)
   (get-mru-window nil nil t))
                           =




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 29 Nov 2024 15:54:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 29 10:54:10 2024
Received: from localhost ([127.0.0.1]:44132 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tH3Jp-00082Z-GU
	for submit <at> debbugs.gnu.org; Fri, 29 Nov 2024 10:54:10 -0500
Received: from mout.gmx.net ([212.227.15.18]:48703)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tH3Jn-00081y-Ab
 for 74246 <at> 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@HIDDEN;
 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
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
Message-ID: <08f46ed1-e489-4859-8a25-ba7dc4262b95@HIDDEN>
Date: Fri, 29 Nov 2024 16:53:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Juri Linkov <juri@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
 <87jzcn1af7.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <87jzcn1af7.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:4e0s2dguPx4ArVO6ikx1rAWv6oA6eM7qJPUe/88cl9nFMiqIRhS
 18sYzDyIxuCwu1re9338L40FhCHFClAMNTJ7YjUbPoudCpuU3xTOnIq4tm8hG+j0CtFWsHM
 Wr8yvWAufKMRd2shWXy+3T9eHWMo6yLNMYhyrJQ6MGc/8qlkgYauceJpVlyiaB8DEHkBh+o
 sxdPg1oZxehwXUhlMJclQ==
X-Spam-Flag: NO
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+zPXmXJTPZUnj0ejrBgKepxmzFQCF2lNDKpV8NhzjYqCSEaVSg1qZ
 MCS/7v/i6qzlWupq/SqKF1Se4Xu4AzNYPYztuu5sKx0KbAaBXxR3a3SeSdxTGkPvjseoz5pOg
 uxL98A1EKLzjH8Osc761tYrzWcXTAbnEdls1gXA81D9y+Og4hvO7a/vZ8XJTs2mt6lJXHoLBC
 WzU/Nv75I9j2tL9vWDY5t79RM9NYSFxaE9MLZuy3joVCbwLqkQq1jTAA96GsGxG9qH7XiPuBJ
 C2Wz9Iie8F81v8DXKbhgbNqoXHwf5e3DKqANIwFakHMTTrG/zbG/o6E/s3jnq2VwaOCs+N858
 rCzkdCyiJ5FQJk5TPMcI4EezVbttOv
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 28 Nov 2024 18:37:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 28 13:37:34 2024
Received: from localhost ([127.0.0.1]:39705 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tGjOP-0001jh-RY
	for submit <at> debbugs.gnu.org; Thu, 28 Nov 2024 13:37:34 -0500
Received: from relay9-d.mail.gandi.net ([217.70.183.199]:49161)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1tGjON-0001jO-9h
 for 74246 <at> debbugs.gnu.org; Thu, 28 Nov 2024 13:37:31 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 57882FF804;
 Thu, 28 Nov 2024 18:37:02 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN> (martin rudalics's
 message of "Thu, 28 Nov 2024 10:28:23 +0100")
Organization: LINKOV.NET
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
 <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
Date: Thu, 28 Nov 2024 20:27:08 +0200
Message-ID: <87jzcn1af7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> - Use the existing 'category' alist entry like
>
>   (pop-to-buffer buf '(nil (category . image-dired)))
>
>   This was my original idea.  The downside of this approach is that if
>   "category" were used for its already existing purpose (whatever that
>   is), the new purpose we'd gave it here would side-effect the behavior
>   for the existing purpose.

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.

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)))

> - 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")))

> - 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)))

> - 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.

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)))




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 28 Nov 2024 09:28:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 28 04:28:37 2024
Received: from localhost ([127.0.0.1]:36665 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tGapB-000663-AL
	for submit <at> debbugs.gnu.org; Thu, 28 Nov 2024 04:28:37 -0500
Received: from mout.gmx.net ([212.227.15.19]:40509)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1tGap8-00065o-Fi
 for 74246 <at> debbugs.gnu.org; Thu, 28 Nov 2024 04:28:35 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1732786104; x=1733390904; i=rudalics@HIDDEN;
 bh=SVrjjGXIVTkbZfxajKfFAPLkFnKqXwg04ACjYW5flMo=;
 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=Z7AHOflZPPIlZIi4Xa9voEkwApNrSB1r72vwOMfHjPUGxJB/V4ak+N/nlxpKBYcf
 qzbRmtrYQxP+tVJV115LrgvBVxhZw4BJxGemTppz6bA6aPd8DCMyJK3iwKQRAnQ+N
 FHZF5pXVYay+EjjuOgGQJDdigAsLZdBW3BA7OcCQ40uUUq+myjOw0wp76G0e0IZJm
 MFI9AO1EPMigQStS8L4dZBlDtlinS1Y+6u9jpqCzo/0CC98VYsZ/XS4cN2xVEOnwp
 /p5TTaMT9GWGqOmb4gnSQkWziRUnDm2Y9IOsP0oA0pGX5faqS/vwFpyMM/HzFsbF2
 beR5QJbgmaAo0mdkXw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.21]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MSbxD-1t5uW91wZF-00PHFl; Thu, 28
 Nov 2024 10:28:24 +0100
Message-ID: <06f264c8-b1a1-4a7f-8fe9-1ca58b2343ff@HIDDEN>
Date: Thu, 28 Nov 2024 10:28:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Morgan Smith <Morgan.J.Smith@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
 <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:AXp/lFK6JWzs9z/3ApNgARvPw/SVbZldwgBtekqBQ3j5f0JmlDE
 o6WkJvManT4iAsFGUA5GXx/vyUy50DdRLeu8Sb/xhzMEx88id3sqX9EUGGvx2aRogP1CJme
 l6oPRyHpBqCBKXISXs2pDkOz24WeVZbftp2vVs6/XZz0qYE0lajL9CyzUmwT22eKgI034jj
 FZKckEbKPwY7tEpXK1Jkg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:RgZ4GRpl9zA=;kasUT31zYaC/dyKG13hSVCBU2+z
 ZG8/961NcfC7mcFBN3ZLhXldrHOOEoEdcXYcclJ3SpfBRERYYOHsPh1/Egu66/ZVpVVo6MSku
 cdMvbhjO3cLCgvX9Sa8LVDOO1HvgMeOR+SPo2C9VcowBwp/45la3PyGac8aNVTAwG24+D7Q4u
 4lQmKFVIRQ0+Jyb8n45PCTLCbotzcEzjWKcYge2IrM9SH8Bilme8SRvEdk4FSwRs/MjrG3gEg
 pz6Rh3yCSpa6ATqblX2ujK6B8kCN/xMMfR9UVYSH5DEFhxXfnlOPp924RxE+81wl2L4O8z1FV
 rKXD/ljDOvUanikoRmeS3ab0Y8f/hlXnmIatyeruiTnJyMMiwwAEyhnTgus339puxaZMUqMKv
 SAccrkCZJLb2jOlpZGRZYdPNwDB52feFetCxGGfsbX2GO7RYcpWaD4EFaNMYldWrgit1ZD+Go
 6ZeUkMO/wajkglgQljjc1Bb77ZlDCQSwiBRggC7CXhxYsPyKXymrmsjsQzHTA3CpoYi9NrmlC
 Lmwr+FW63q8wNbUQ6wMeBN3CqJJDfoPB1JW7LzUQzXv4phkD2encdKB1S2+mWsRcn3Mb6MDWG
 K+x0CvObCRgh5xs90tT7sT6DrBj6OUR/64PNuEyiFuGstufX6S2H2voCuDdylGHw3rnR8kbbY
 Xu0xbQYgXFWp/qj7G1FMbXDNw+GqVXekRK2bWFLnpPTbDsRVB+0LXAqOd5DGdKfXNvzm2mymP
 idFNPw7SrQJOPLk7lX6pzYPidbSL1KL+1z0ShPxDlwY5giP2KaLmlxqaLfnhIFfZfvbkT4Bn3
 zXRFJSP5EaS+PaDuuaMQHRCVIsuPtuG2mNnoplkpO8JXOIbO/FfV2NKcn+rXxn3tkkFGfg0AQ
 w4zU69l/nuE6q4xmgmBZKuLMHe0alSHmt7ntBWlL7m1tnwrOtv5Rpd1m63Xbp5lWbX/IJV2jh
 oxf39MmYrFlZUyQXSxO0AjxrmGd3DyroVkE/CtFjmwXfCSI7VvMY2fWm3FXPG+xyFdc5B55lA
 DHSNKY7j386Mc90+Gu38bF7BpX7M/fcsrhkeJAEeynTlk+1cS4rt1b1ahQJ63HGNIOmZrDKDj
 8Cg33bMUzessgtrL0y6fTK8GiYt6xj
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  > I initially explored this option but was weary to use >
 'find-file-noselect-1` as it looks like it should be an internal > function
 and is used only in the file it's defined in. You're right. Which means that
 we should try to "promote" and document that function. Let's see whether
 people see any problems with it. 
 Content analysis details:   (2.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
 The query to Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243
 for more information.
 [212.227.15.19 listed in sa-trusted.bondedsender.org]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (rudalics[at]gmx.at)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
 query to Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243
 for more information.
 [212.227.15.19 listed in bl.score.senderscore.com]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [212.227.15.19 listed in list.dnswl.org]
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [212.95.5.21 listed in zen.spamhaus.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [212.227.15.19 listed in wl.mailspike.net]
X-Debbugs-Envelope-To: 74246
Cc: 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > I initially explored this option but was weary to use >
    'find-file-noselect-1` as it looks like it should be an internal > function
    and is used only in the file it's defined in. You're right. Which means that
    we should try to "promote" and document that function. Let's see whether
   people see any problems with it. 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
                             The query to Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              for more information.
                             [212.227.15.19 listed in sa-accredit.habeas.com]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [212.95.5.21 listed in zen.spamhaus.org]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [212.227.15.19 listed in list.dnswl.org]
  0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
                             query to Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              for more information.
                             [212.227.15.19 listed in bl.score.senderscore.com]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [212.227.15.19 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (rudalics[at]gmx.at)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

 > I initially explored this option but was weary to use
 > 'find-file-noselect-1` as it looks like it should be an internal
 > function and is used only in the file it's defined in.

You're right.  Which means that we should try to "promote" and document
that function.  Let's see whether people see any problems with it.

 > However, I do like this solution the most.  Attached is a patch almost
 > identical to the proposed function.  The proposed function would be
 > perfect if it contained the line '(display-buffer buffer t)'.

I'm currently investigating (in the context of Bug#74361) the
possibility to provide an option for reusing a window that already has
shown a related buffer.  'image-dired-display-next' would indirectly
pass that "option" to 'display-buffer' and the latter would try to find
an appropriate window with the help of a window parameter reserved for
that purpose.

Below are ways to implement that "option".  Common to all of them is
that 'display-buffer' sets up a window parameter for the first window
used to display such a buffer and 'display-buffer' would search for a
window with the corresponding value ('image-dired' in this case) for
that parameter.  And the parameter would stay with the window until it
is explicitly reset or the window gets collected.

- Use the existing 'category' alist entry like

   (pop-to-buffer buf '(nil (category . image-dired)))

   This was my original idea.  The downside of this approach is that if
   "category" were used for its already existing purpose (whatever that
   is), the new purpose we'd gave it here would side-effect the behavior
   for the existing purpose.

- 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.

- 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.

- 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.

Adding Juri to the discussion.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 28 Nov 2024 00:32:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 27 19:32:53 2024
Received: from localhost ([127.0.0.1]:35549 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tGSSi-0004cH-PK
	for submit <at> debbugs.gnu.org; Wed, 27 Nov 2024 19:32:53 -0500
Received: from mail-dm6nam04olkn2098.outbound.protection.outlook.com
 ([40.92.45.98]:40935 helo=NAM04-DM6-obe.outbound.protection.outlook.com)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <Morgan.J.Smith@HIDDEN>) id 1tGSSg-0004by-ML
 for 74246 <at> debbugs.gnu.org; Wed, 27 Nov 2024 19:32:51 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Z+Au6wq68o9mGDhFfwYD813hzhMkn2XC7CL+a+LYqPhsd3F/CoHgd4WULwWxV3LQ6oM4Rnny19+Pf87JCR1N0h63WFHdw78V4lNUURkz9tKRS8xQI85XHCVpvI3AFGvlRpL1U/AvMjL/HVHxNqyEu8+WECbdwflxSunc7Npb3Sk7dt831Ov7Z7gOBvcCBaLW9hIcZROj5tdvq8Et4QIZh37VrmFnovjOugxq2RYVAVemxfwYsJOQYk/FHmPHl4Crq9bbOIspECdFRzSmyGtG2CdrVRyJ2jLKK+LSG/if8NGVS1qLsuEIkWJfqrek6SB069k9izi6et+19V5BB7flWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A5TwwU1ihytvYezQyWkMJsCyDObNMyKksNmFsYUuLiM=;
 b=JbRYCy3g1ILrC06hWWAI0wGxo6Q08jHc6DWncs2pqUIzg05vieggvNdkCQ0RPftTojzENmPnKYqO+5hiaqpemp9VgTsq8L4w8E91uzjW3XEiP8LxrSA/+J9PXF3bEXdyKMfevfoUqGb7paCqXImxIU8svntaI/o6Qg7HrRS6OTGA9I5cXqr7pjBIBV2E6wV9KN75bgUo/DStFRZBsCY0IBXCbugiuTljFzIGXpwoh7ciTXEqwSMBUlx2JeNP3H23HhD1wVwhrznjPImX6iqTyx4D8qNpcRJQxd5uYiuV+eZYKFg4Igi/pZav7AcFKNCeV4PmJfOf/tnQTLaLRqZgQA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=A5TwwU1ihytvYezQyWkMJsCyDObNMyKksNmFsYUuLiM=;
 b=VoKyoOJDCv1lmflHdrhLgl8kxfEVoHPZZ3SjXKqjQRnwlLSx9T9IxgfN83a74uwnCGfjHBzywRnXEoQDm9odmJepbzsIY5Oust1Pa07yLxodqNaPI6bdbxNRg3HATSSGjzBQS6bnh5cysE+Lxr86z5kRQ7qnZ0OnEhJTxzOhBaoyiMEpvsT7Qy1thT6ubSGZ28vidcjnBHRBIiqUgKCPOXJrIOrI3k8cVRkhOE+MKn/tLZkXvJyVHePHrKQSeYh3OJA+sApIkeK6cvqk2oc0dTMAIH3QTXQy1Ojq7d04U5b+VewacOfJ36HP9pgT0nzlkH7KD56BSku2E5YFYYr/tg==
Received: from CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:610:1c4::17)
 by MW4PR84MB3145.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:303:1e1::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8182.21; Thu, 28 Nov
 2024 00:32:43 +0000
Received: from CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM
 ([fe80::5c77:7a58:48ed:9aef]) by CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM
 ([fe80::5c77:7a58:48ed:9aef%4]) with mapi id 15.20.8207.010; Thu, 28 Nov 2024
 00:32:42 +0000
From: Morgan Smith <Morgan.J.Smith@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
In-Reply-To: <86a5dqm9gl.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 23 Nov
 2024 14:16:26 +0200")
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
 <86a5dqm9gl.fsf@HIDDEN>
X-Hashcash: 1:20:241128:rudalics@HIDDEN::Jdn0MMq9K6thQd9W:2gHR
X-Hashcash: 1:20:241128:eliz@HIDDEN::Lem42GKmX50BTH4e:3JUO
X-Hashcash: 1:20:241128:74246 <at> debbugs.gnu.org::gWmGdseeFuzL5Ol6:1uPQ
X-Hashcash: 1:20:241128:stefankangas@HIDDEN::KFb9FVhUCpZy+G1M:4bGE
Date: Wed, 27 Nov 2024 19:32:43 -0500
Message-ID: <CH3PR84MB34249702569748082C9BBF9CC5292@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
Content-Type: multipart/mixed; boundary="=-=-="
X-ClientProxiedBy: YQBPR0101CA0209.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:c01:67::9) To CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM
 (2603:10b6:610:1c4::17)
X-Microsoft-Original-Message-ID: <878qt4nqok.fsf@HIDDEN>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PR84MB3424:EE_|MW4PR84MB3145:EE_
X-MS-Office365-Filtering-Correlation-Id: 9cb0642a-3052-4165-0e4e-08dd0f442aef
X-Microsoft-Antispam: BCL:0;
 ARA:14566002|15080799006|19110799003|8060799006|6092099012|461199028|7092599003|5072599009|440099028|13095399003|3412199025;
X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?s5sLHTyfA/oxPHQGMrq7sAr1typKjP9hg1bpgVocMXrw5EJnAHnP0OGkO0kQ?=
 =?us-ascii?Q?lFbDoFyzg9iA4X3+PtJDbed7wJRhrFFhD0Ol17+8fNVCMIlxMP+oSt0NiDzU?=
 =?us-ascii?Q?XwNaFWfeCLzD89WPQbOqUw3mT9iwFOnxt9CBObH8Ql1MBoj2ok2Xz2pPCKzj?=
 =?us-ascii?Q?Apj1wwkv/FiD432YbMC3zd9z89XGvonvVL1wBHw1M4Lyv6D4H986h45BoBB+?=
 =?us-ascii?Q?UCy7Pqccxuhaoguo2HrL5KSgo5WzBA6vEBqQz3oilPPzHAi1VMC2UBxZoUYW?=
 =?us-ascii?Q?9JZdiaG/bCsuP8bBUAWz/1GZ2okhF5Lh0mvv/vh7M1ck1K+8+DzwsWOs8Z0M?=
 =?us-ascii?Q?PVryq8ssY8frUMFVj6A4yRcyYCnpo0L1+vzspL75p9QyE+FRUfa8CTy81xK1?=
 =?us-ascii?Q?KPBf4a8dQfIcQMEpLea01Nno/tduvGb+8PGjTkYNB8QN7P2uE8KNMZ6tGmqf?=
 =?us-ascii?Q?ew42TyxvjaB/BtrWpgcTy46+t7RKxA1+VnS46KyjJDqR6qDzmwfwouV7pOkU?=
 =?us-ascii?Q?kJHW6HYNH9tFjRoUOb4PrDzrrAe2RkRNLAwzeI/wbrf8ARmQyWqatm37XKZ4?=
 =?us-ascii?Q?D78xuz+kgJ5qsonFUGFPAQCmQqLRvuS/x0JmyPQIz9gwdPPKrLEacqfrRMoF?=
 =?us-ascii?Q?fR9419lK2S1h/yumUgnubXWXwiJx0paXCySY7FavmQYybuLX4zE+uz1cjmuk?=
 =?us-ascii?Q?IdMAQS9CgAERoNbJSbyzCLj1Bo6uCepdrsXEChdp7RNKqxohcqDTdvoD4YsC?=
 =?us-ascii?Q?z6HJQKXVNRIUoBWgzqwcGsrj7fsjTi2mjgMyeD6r+UwY9QbcxnMaIEZ4oF4r?=
 =?us-ascii?Q?JmT3YDd3alkmcV/QAtPVEWAYMwHpvHy1x3n99IMKpLrQa1d5YqFBzEgVP4LO?=
 =?us-ascii?Q?Wrvpg9pqNlSBeIsSprlx+ZUFSmxUX+KVsmF0BrC+AU7aAG9xmzGyfqdVudnQ?=
 =?us-ascii?Q?TCG78OLR4dn6XuEosEhof3gI8vWTSePp5CI6V3MkbqcA6YjYdsJC3LKgIYDR?=
 =?us-ascii?Q?RZi6PccB0jQXlcWFQ/a4X80j0IJiiZl/eFoj6S1yz2fBdejMJju582HeAHyx?=
 =?us-ascii?Q?7zLu667KpKsqaluHmRhN3qeuaeMmbXxDxhNthG1fsT5+pPbInNk=3D?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?pH21tUTO6t0GGsYJzdoI/20F2gPw/0r7EdY8VPv2NHbCEUDRrFPnNXvPm7dN?=
 =?us-ascii?Q?q9fcxHxNyA3xApWTnSOf9y7HBRd/muXodeqnKzUpZR8BJdXgty4Q4tQOaNnc?=
 =?us-ascii?Q?gXpGn5yvVnnEeZ9TqODKKBujxp1dF4cSIs9mvrGj/nD0p9O4mbFLsiFteAMB?=
 =?us-ascii?Q?QA/ajBS9qR7JiTpaLtgsCxEQ2IGT656PuSOMKJuy/W2emSQkVNnqcLe4I87T?=
 =?us-ascii?Q?uLKda2PweTWcTADu9lzt1yye1R/Up7aBruibcDSzoYo39jxvhBGxCyyCdtzH?=
 =?us-ascii?Q?1KCz+60zhLlFBPNBcR6e+sR4rDnmbDEt3Yj+BzUCqDs0Xubq4cYkgdUF5SiD?=
 =?us-ascii?Q?Ow04ZLmCGyQwzSIbM278U4xQ0BY1m9jGBSsdRDozuwWwqrsN957wqY/KGVIG?=
 =?us-ascii?Q?ez7bnFIMuTha89rkt3to69RxSUeJCgn57GpFl8Pq8aU19Srgzp2PYxpuLdZT?=
 =?us-ascii?Q?VLJ99uKXaLuNHPO3kCjvuZtcuDJ1xtrj2OP19TsULciKC2zv5kJqYcjqPx8+?=
 =?us-ascii?Q?1N/Ir1qZ9tUw8jflZxApV8dRxyH9Nbg0zGRtIdChLhLTUiJ+ARjKRLk5V5YN?=
 =?us-ascii?Q?v2oTCCStOGYQLK87i80RcHOgAilUnMyGr9kQCjHnp8IORhvmTYSkALEHX+F6?=
 =?us-ascii?Q?rwcsiQ5nX3xZzMmVpy/s+3bFgtrfoA6Q2ECOHpJnqCfkEaEyAIeTaTEJcjYo?=
 =?us-ascii?Q?XxIRlbpr80EcItoESlZW9YQ7upH0c1M6PUK8oBiL/k3zvAN+tFfXlj5Au08t?=
 =?us-ascii?Q?lykYW88NElx0bY9MSs732lXzJ/I874S0LiGR59SDLSxca1ILU6MOVEoAmqbc?=
 =?us-ascii?Q?nqSJf2V9JbkEskdt0nRvh1BKuKtHRnYDkh6ff2y61kw5UJmLyvV1bh079vZi?=
 =?us-ascii?Q?QIO/g5L0HuYiranCQHz+ciy5H26j939PlkMgEWeuaCt/eV6qTRgs2XZb4Nnb?=
 =?us-ascii?Q?Imd6hV1U5hUAN8Kka3AFm63Q20Y0PA8VobGsF2/OWIUPedOnKl768sg3vD7L?=
 =?us-ascii?Q?zDHOokKL/ijfAwogV4xUp29B1ec81eLdHifTgoacCSj2cvRXB7tlLdfFr8i4?=
 =?us-ascii?Q?l2SsILA95jsy4ksc0x1QHATt0DDjUaJTLsqK2x42leR2fj1JFRAkQf7Gzaw1?=
 =?us-ascii?Q?DQaoCRt8iQ35lN6HH2q/NalHHVTF3FyLfUYJNQF1PA0pzqcS7MDJjpzGnIMK?=
 =?us-ascii?Q?GgilWdMvqIUJVOhw6prTfDgJly6y+nzz9h3POzhZNQeZ+qVRFDhlX0eg8qpj?=
 =?us-ascii?Q?SkgwNrNXKDumnzIMz0nPrRaB8Uw2H9DYiHFpdU4Ci/nAaPAUUXxc2j+9wvPY?=
 =?us-ascii?Q?MCCNUpaJ/5+Zqhwdy5lE8tyT?=
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9cb0642a-3052-4165-0e4e-08dd0f442aef
X-MS-Exchange-CrossTenant-AuthSource: CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2024 00:32:42.7866 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR84MB3145
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 74246
Cc: martin rudalics <rudalics@HIDDEN>, 74246 <at> debbugs.gnu.org,
 stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain

Eli Zaretskii <eliz@HIDDEN> writes:

> Ping! Morgan, could you please try Martin's suggestions and report
> back?
>
>>
>> FWIW, I would rewrite 'image-dired-display-image' as the (largely
>> untested)
>>
>> (defun image-dired-display-image (file &optional _ignored)
>>    "Display image FILE in the image buffer window.
>> If FILE is an image, the window will use `image-dired-image-mode'
>> which is based on `image-mode'."
>>    (declare (advertised-calling-convention (file) "29.1"))
>>    (setq file (expand-file-name file))
>>    (when (not (file-exists-p file))
>>      (error "No such file: %s" file))
>>    (let* ((buffer (get-buffer-create image-dired-display-image-buffer))
>> 	 (window (get-buffer-window buffer)))
>>      (find-file-noselect-1 buffer file nil t nil nil)
>>      (with-current-buffer buffer
>>        (if (string-match (image-file-name-regexp) file)
>>            (image-dired-image-mode)
>>          ;; Support visiting PDF files.
>>          (normal-mode)))
>>
>>      (unless window
>> 	(display-buffer buffer))))
>>
>> instead of doing all that 'kill-buffer' (which could delete the selected
>> window as a side-effect so the final 'select-window' will throw an
>> error) 'rename-buffer' rigmarole.
>>
>> martin

I initially explored this option but was weary to use
'find-file-noselect-1` as it looks like it should be an internal
function and is used only in the file it's defined in.

However, I do like this solution the most.  Attached is a patch almost
identical to the proposed function.  The proposed function would be
perfect if it contained the line '(display-buffer buffer t)'.

Morgan


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
 filename=0001-Reuse-display-windows-in-image-dired-bug-74246.patch

From 7d0d9133b5276565589aadea9c0804522ed3cc64 Mon Sep 17 00:00:00 2001
From: Morgan Smith <Morgan.J.Smith@HIDDEN>
Date: Wed, 27 Nov 2024 19:22:27 -0500
Subject: [PATCH] Reuse display windows in image-dired (bug#74246)

* lisp/image/image-dired.el(image-dired-display-image): Reuse
the buffer if it exists.
---
 lisp/image/image-dired.el | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/lisp/image/image-dired.el b/lisp/image/image-dired.el
index 83745e88f09..29863acea8e 100644
--- a/lisp/image/image-dired.el
+++ b/lisp/image/image-dired.el
@@ -1268,18 +1268,15 @@ image-dired-display-image
   (setq file (expand-file-name file))
   (when (not (file-exists-p file))
     (error "No such file: %s" file))
-  (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)
-      (rename-buffer image-dired-display-image-buffer)
+  (let ((buf (find-file-noselect-1
+              (get-buffer-create image-dired-display-image-buffer)
+              file nil t nil nil)))
+    (display-buffer buf t)
+    (with-current-buffer buf
       (if (string-match (image-file-name-regexp) file)
           (image-dired-image-mode)
         ;; Support visiting PDF files.
-        (normal-mode))
-      (select-window cur-win))))
+        (normal-mode)))))
 
 (defun image-dired-display-this (&optional arg)
   "Display current thumbnail's original image in display buffer.
-- 
2.46.0


--=-=-=--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 23 Nov 2024 12:16:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 23 07:16:39 2024
Received: from localhost ([127.0.0.1]:56962 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tEp42-0003YZ-R5
	for submit <at> debbugs.gnu.org; Sat, 23 Nov 2024 07:16:39 -0500
Received: from eggs.gnu.org ([209.51.188.92]:54072)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1tEp40-0003YJ-RS
 for 74246 <at> debbugs.gnu.org; Sat, 23 Nov 2024 07:16:37 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1tEp3v-0004xU-6F; Sat, 23 Nov 2024 07:16:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=SWRWBHQ6KiHPxcJp19IRr8BN1NBENBgyMkrMTNKO7Qw=; b=q9RYxh9u03ER4CmL/TL6
 X/F1c+C1whaHc7WU4kvIntqIj/yG8sPpdXfTnVALi2z8HLFcnuODhO5ZATtER50aR+cqo0RNU3Wdh
 Y8hn5QeIFVBHRKzcYuYdvm0mbMnNLqIFQY1MIRaz98455w+auzn8mU+S3JQgsgOYYQLi6z0VZbFjF
 0Yar6+anLxY2X0T2veid0922/63WudUhrpBLppv0tfOByOKO6N4/wzGiRuPNBb3414HUiQE7N6fvi
 pC3ckAFlpDs/aR2Tzd0sj9q+0m2aElbJxUVZG4vDfz4BL0QJzKGYwy+e9lYZun6ud/Y2uSy7X5xnv
 Ehnh68qesX3ztw==;
Date: Sat, 23 Nov 2024 14:16:26 +0200
Message-Id: <86a5dqm9gl.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Morgan.J.Smith@HIDDEN, martin rudalics <rudalics@HIDDEN>
In-Reply-To: <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN> (message from
 martin rudalics on Sat, 9 Nov 2024 18:36:12 +0100)
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN> <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 74246
Cc: 74246 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Ping! Morgan, could you please try Martin's suggestions and report
back?

> Date: Sat, 9 Nov 2024 18:36:12 +0100
> Cc: 74246 <at> debbugs.gnu.org
> From: martin rudalics <rudalics@HIDDEN>
> 
>  >> When using image-dired, one can use SPC (image-dired-display-next)
>  >> repeatedly to display successive images in a dedicated buffer.  However,
>  >> it seems to choose a different window each time I press SPC.
>  >>
>  >> I can reproduce this in "emacs -Q" when I have 4 windows.
>  >>
>  >> The following patch works on my system.
>  >
>  > Thanks.
>  >
>  > Martin and Stefan, any comments or suggestions?
> 
> It's a problem we've seen in other contexts before: For historical
> reasons 'display-buffer' by default tries to use the least recently used
> window which changes whenever we display an image in it.  Juri invented
> the 'some-window' buffer display option and I quote the corresponding
> entry from the Elisp manual here:
> 
>       The above describes the behavior when the ‘some-window’ ALIST entry
>       is ‘lru’ or ‘nil’ which is the default.  Another possible value is
>       ‘mru’.  If, for example, ‘display-buffer-base-action’ is customized
>       to ‘(nil . ((some-window . mru)))’, then this function will prefer
>       the most recently used window.  This will try to display several
>       buffers from consecutive calls of ‘display-buffer’ in the same
>       window.  Consider a configuration of three or more windows where a
>       user wants to consult, in a non-selected window, one after the
>       other, the results of a query spread among several buffers.  With
>       the ‘lru’ strategy, Emacs may continuously choose another window
>       because the least recently used window changes with every call of
>       ‘display-buffer-use-some-window’.  With the ‘mru’ strategy, the
>       window chosen would always remain the same, resulting in a
>       predictable user experience.
> 
> So I think that Morgan should try to use this approach first.  But if
> the image is always displayed in 'image-dired-image-display' mode then
> the appropriate action function 'image-dired' should use is
> 'display-buffer-reuse-mode-window'.
> 
> +  (let* ((buf (get-buffer image-dired-display-image-buffer))
> +         (windows (and buf
> +                       (get-buffer-window-list buf t t)))
> +         (cur-win (selected-window)))
>       (when buf
>         (kill-buffer buf))
>       (when-let ((buf (find-file-noselect file nil t)))
> +      (dolist (window windows)
> +        (set-window-buffer window buf))
> 
> Is this supposed to show the same image in all windows that previously
> displayed 'image-dired-display-image-buffer'?
> 
> FWIW, I would rewrite 'image-dired-display-image' as the (largely
> untested)
> 
> (defun image-dired-display-image (file &optional _ignored)
>    "Display image FILE in the image buffer window.
> If FILE is an image, the window will use `image-dired-image-mode'
> which is based on `image-mode'."
>    (declare (advertised-calling-convention (file) "29.1"))
>    (setq file (expand-file-name file))
>    (when (not (file-exists-p file))
>      (error "No such file: %s" file))
>    (let* ((buffer (get-buffer-create image-dired-display-image-buffer))
> 	 (window (get-buffer-window buffer)))
>      (find-file-noselect-1 buffer file nil t nil nil)
>      (with-current-buffer buffer
>        (if (string-match (image-file-name-regexp) file)
>            (image-dired-image-mode)
>          ;; Support visiting PDF files.
>          (normal-mode)))
> 
>      (unless window
> 	(display-buffer buffer))))
> 
> instead of doing all that 'kill-buffer' (which could delete the selected
> window as a side-effect so the final 'select-window' will throw an
> error) 'rename-buffer' rigmarole.
> 
> martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 9 Nov 2024 17:36:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 09 12:36:28 2024
Received: from localhost ([127.0.0.1]:54366 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t9pNs-0006yW-3R
	for submit <at> debbugs.gnu.org; Sat, 09 Nov 2024 12:36:28 -0500
Received: from mout.gmx.net ([212.227.17.21]:42853)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1t9pNq-0006yI-4P
 for 74246 <at> debbugs.gnu.org; Sat, 09 Nov 2024 12:36:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1731173776; x=1731778576; i=rudalics@HIDDEN;
 bh=KneI075Va+6lVn8CNZsG+XiNaDeiO41jykkePdVdMQU=;
 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=oBF6yskz9L9QEKWDdJ478/UmfnrYR2t4PxUUaQXxt4E+KBDGWC2NqdmTTOQ/AVyf
 yVd6I6jwfzg6iTR8SXyKYCDlzhGub0zkfR8tBhqscg1uG/pXocJcO0VO867NTunBW
 2kPkZMY/aBvbttrreiTN3k9sqzj2ZpB7JNNUB0qtr9KFXl2vEiC6Y2hA8mq08SBUF
 d8wImepDLalSI7m9yXlj5wr6eW7MpBmkwUMIHAvbl70yB8ueaL1ROsRm1uy+VwDq1
 iePJIwZnl7WMoRy3uV+rwdlY1Ega8Xc8KNOFsZaMkEFLr6FXj8Ez4xyKVlvuiqJ+h
 yyYWtAUySkTtqWWcOw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.96.102]) by mail.gmx.net (mrgmx104
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N7i8Y-1tvcoc2nwo-017HaC; Sat, 09
 Nov 2024 18:36:16 +0100
Message-ID: <a4e687f5-487b-4cb1-8dee-7559f5f0796a@HIDDEN>
Date: Sat, 9 Nov 2024 18:36:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
To: Eli Zaretskii <eliz@HIDDEN>, Morgan Smith <Morgan.J.Smith@HIDDEN>,
 Stefan Kangas <stefankangas@HIDDEN>
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 <868qtsmydz.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <868qtsmydz.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
X-Provags-ID: V03:K1:p/zqcD9YFJxH6aYdgfHPBbBwMDM/J8s2TDZ3hTTePYnAye66JU4
 paOhwdr0/pUtj78v584YgCwO2vcJv1WBRjziTyAudoT8/RmIGv4iwc4aSlhyVZXSuNZxPyR
 QRD+RRIhW6nq1zuGQhgsBTQ3IiOlTE1PLK61U6Mmvb8h68toqzh86iPoGHtHRDsz9GfgGAu
 BmKathKg3rzUkKmTViPig==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:lRmZa2kyaWw=;R/al+HjgBkTZppZwHFd8mG0p4lK
 pPLMnPPmusTLON1n8rQ4jOP8yvkbckD4/sJgBpiFw/m29rR7kfqm4l7p//xCOsbSuVQ0JuW2e
 BnRu0MlgCEwuMGPn29YO5omm8l3JZvyG3Zyh8S6Jh2379kOYPzyd90uXPpKlylKDAwkKqhuD+
 p2QXmk2YYlfBFq0a/0/mo8gL+LeaXLzB5MJBT81brlgqPlbvTstOfp8iePnWWr9KMT54t9mCU
 PPOOhEibU8p5wU6CIphnjIRl/akAt1vXISq0w0xuzDqufpq07GFGyzsjpCYc8t39ZAKdZ42R1
 SyXSe15azShDDZC0fmjgw5mdJNKXpY9YTxPim5WNhq/XtHWjqpsM+ST+JPB25o17PT/HQHVb0
 /iN61aOC/o3MV1jd3u5h6F2jHl5+aKB80Cz5YM6Whsxh8KwN28sAYjaoQruFIRGm3A8ZE0cYq
 KqKOEUhwNMFTDdnBeaSTuTetonFr2qhOauQmACjMWHgeX+tBHR3k7/z2UlSFs0lcVKfs6DPj9
 /6F2sK/j8Pt+nDhXjsXw3Bw1VuEuQLfyDdNXtZNGTFv+hRklPAgicivAWbbDwV30u34w71mix
 xr+aO513bE/PS66EpD4jUte/TCiCWEIURpiDB/CIqgCJ2BxGmlY06XHMZKsKYHbLzITttgW1p
 MZhaukaKauMA+sZtiXs/A16y3DJCnN8Xm2dT72LMDA1kjUzsGkLlap58CxtrAiW9dMSTWjeKe
 o3IPG7fMMBM8/kKhFv6dz+G7pyfENNWfKK3HHfONfdF+AoRwIGxsQhrbCeppHDb3Ze8TtaBXA
 JHLq9wErdhABKxV3n3nsjYaR6YCtj/d0p4TWtZ3qJrdsOp3ItaiS8AxY55YevmZlWdyQCTTqD
 n0dIJ3E8z4hDdSNFRtcqoTEv16ody2pjz0BNh1PtCBEPCYkYo6Bn8rMuC
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74246
Cc: 74246 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

ID4+IFdoZW4gdXNpbmcgaW1hZ2UtZGlyZWQsIG9uZSBjYW4gdXNlIFNQQyAoaW1hZ2UtZGly
ZWQtZGlzcGxheS1uZXh0KQ0KID4+IHJlcGVhdGVkbHkgdG8gZGlzcGxheSBzdWNjZXNzaXZl
IGltYWdlcyBpbiBhIGRlZGljYXRlZCBidWZmZXIuICBIb3dldmVyLA0KID4+IGl0IHNlZW1z
IHRvIGNob29zZSBhIGRpZmZlcmVudCB3aW5kb3cgZWFjaCB0aW1lIEkgcHJlc3MgU1BDLg0K
ID4+DQogPj4gSSBjYW4gcmVwcm9kdWNlIHRoaXMgaW4gImVtYWNzIC1RIiB3aGVuIEkgaGF2
ZSA0IHdpbmRvd3MuDQogPj4NCiA+PiBUaGUgZm9sbG93aW5nIHBhdGNoIHdvcmtzIG9uIG15
IHN5c3RlbS4NCiA+DQogPiBUaGFua3MuDQogPg0KID4gTWFydGluIGFuZCBTdGVmYW4sIGFu
eSBjb21tZW50cyBvciBzdWdnZXN0aW9ucz8NCg0KSXQncyBhIHByb2JsZW0gd2UndmUgc2Vl
biBpbiBvdGhlciBjb250ZXh0cyBiZWZvcmU6IEZvciBoaXN0b3JpY2FsDQpyZWFzb25zICdk
aXNwbGF5LWJ1ZmZlcicgYnkgZGVmYXVsdCB0cmllcyB0byB1c2UgdGhlIGxlYXN0IHJlY2Vu
dGx5IHVzZWQNCndpbmRvdyB3aGljaCBjaGFuZ2VzIHdoZW5ldmVyIHdlIGRpc3BsYXkgYW4g
aW1hZ2UgaW4gaXQuICBKdXJpIGludmVudGVkDQp0aGUgJ3NvbWUtd2luZG93JyBidWZmZXIg
ZGlzcGxheSBvcHRpb24gYW5kIEkgcXVvdGUgdGhlIGNvcnJlc3BvbmRpbmcNCmVudHJ5IGZy
b20gdGhlIEVsaXNwIG1hbnVhbCBoZXJlOg0KDQogICAgICBUaGUgYWJvdmUgZGVzY3JpYmVz
IHRoZSBiZWhhdmlvciB3aGVuIHRoZSDigJhzb21lLXdpbmRvd+KAmSBBTElTVCBlbnRyeQ0K
ICAgICAgaXMg4oCYbHJ14oCZIG9yIOKAmG5pbOKAmSB3aGljaCBpcyB0aGUgZGVmYXVsdC4g
IEFub3RoZXIgcG9zc2libGUgdmFsdWUgaXMNCiAgICAgIOKAmG1ydeKAmS4gIElmLCBmb3Ig
ZXhhbXBsZSwg4oCYZGlzcGxheS1idWZmZXItYmFzZS1hY3Rpb27igJkgaXMgY3VzdG9taXpl
ZA0KICAgICAgdG8g4oCYKG5pbCAuICgoc29tZS13aW5kb3cgLiBtcnUpKSnigJksIHRoZW4g
dGhpcyBmdW5jdGlvbiB3aWxsIHByZWZlcg0KICAgICAgdGhlIG1vc3QgcmVjZW50bHkgdXNl
ZCB3aW5kb3cuICBUaGlzIHdpbGwgdHJ5IHRvIGRpc3BsYXkgc2V2ZXJhbA0KICAgICAgYnVm
ZmVycyBmcm9tIGNvbnNlY3V0aXZlIGNhbGxzIG9mIOKAmGRpc3BsYXktYnVmZmVy4oCZIGlu
IHRoZSBzYW1lDQogICAgICB3aW5kb3cuICBDb25zaWRlciBhIGNvbmZpZ3VyYXRpb24gb2Yg
dGhyZWUgb3IgbW9yZSB3aW5kb3dzIHdoZXJlIGENCiAgICAgIHVzZXIgd2FudHMgdG8gY29u
c3VsdCwgaW4gYSBub24tc2VsZWN0ZWQgd2luZG93LCBvbmUgYWZ0ZXIgdGhlDQogICAgICBv
dGhlciwgdGhlIHJlc3VsdHMgb2YgYSBxdWVyeSBzcHJlYWQgYW1vbmcgc2V2ZXJhbCBidWZm
ZXJzLiAgV2l0aA0KICAgICAgdGhlIOKAmGxydeKAmSBzdHJhdGVneSwgRW1hY3MgbWF5IGNv
bnRpbnVvdXNseSBjaG9vc2UgYW5vdGhlciB3aW5kb3cNCiAgICAgIGJlY2F1c2UgdGhlIGxl
YXN0IHJlY2VudGx5IHVzZWQgd2luZG93IGNoYW5nZXMgd2l0aCBldmVyeSBjYWxsIG9mDQog
ICAgICDigJhkaXNwbGF5LWJ1ZmZlci11c2Utc29tZS13aW5kb3figJkuICBXaXRoIHRoZSDi
gJhtcnXigJkgc3RyYXRlZ3ksIHRoZQ0KICAgICAgd2luZG93IGNob3NlbiB3b3VsZCBhbHdh
eXMgcmVtYWluIHRoZSBzYW1lLCByZXN1bHRpbmcgaW4gYQ0KICAgICAgcHJlZGljdGFibGUg
dXNlciBleHBlcmllbmNlLg0KDQpTbyBJIHRoaW5rIHRoYXQgTW9yZ2FuIHNob3VsZCB0cnkg
dG8gdXNlIHRoaXMgYXBwcm9hY2ggZmlyc3QuICBCdXQgaWYNCnRoZSBpbWFnZSBpcyBhbHdh
eXMgZGlzcGxheWVkIGluICdpbWFnZS1kaXJlZC1pbWFnZS1kaXNwbGF5JyBtb2RlIHRoZW4N
CnRoZSBhcHByb3ByaWF0ZSBhY3Rpb24gZnVuY3Rpb24gJ2ltYWdlLWRpcmVkJyBzaG91bGQg
dXNlIGlzDQonZGlzcGxheS1idWZmZXItcmV1c2UtbW9kZS13aW5kb3cnLg0KDQorICAobGV0
KiAoKGJ1ZiAoZ2V0LWJ1ZmZlciBpbWFnZS1kaXJlZC1kaXNwbGF5LWltYWdlLWJ1ZmZlcikp
DQorICAgICAgICAgKHdpbmRvd3MgKGFuZCBidWYNCisgICAgICAgICAgICAgICAgICAgICAg
IChnZXQtYnVmZmVyLXdpbmRvdy1saXN0IGJ1ZiB0IHQpKSkNCisgICAgICAgICAoY3VyLXdp
biAoc2VsZWN0ZWQtd2luZG93KSkpDQogICAgICAod2hlbiBidWYNCiAgICAgICAgKGtpbGwt
YnVmZmVyIGJ1ZikpDQogICAgICAod2hlbi1sZXQgKChidWYgKGZpbmQtZmlsZS1ub3NlbGVj
dCBmaWxlIG5pbCB0KSkpDQorICAgICAgKGRvbGlzdCAod2luZG93IHdpbmRvd3MpDQorICAg
ICAgICAoc2V0LXdpbmRvdy1idWZmZXIgd2luZG93IGJ1ZikpDQoNCklzIHRoaXMgc3VwcG9z
ZWQgdG8gc2hvdyB0aGUgc2FtZSBpbWFnZSBpbiBhbGwgd2luZG93cyB0aGF0IHByZXZpb3Vz
bHkNCmRpc3BsYXllZCAnaW1hZ2UtZGlyZWQtZGlzcGxheS1pbWFnZS1idWZmZXInPw0KDQpG
V0lXLCBJIHdvdWxkIHJld3JpdGUgJ2ltYWdlLWRpcmVkLWRpc3BsYXktaW1hZ2UnIGFzIHRo
ZSAobGFyZ2VseQ0KdW50ZXN0ZWQpDQoNCihkZWZ1biBpbWFnZS1kaXJlZC1kaXNwbGF5LWlt
YWdlIChmaWxlICZvcHRpb25hbCBfaWdub3JlZCkNCiAgICJEaXNwbGF5IGltYWdlIEZJTEUg
aW4gdGhlIGltYWdlIGJ1ZmZlciB3aW5kb3cuDQpJZiBGSUxFIGlzIGFuIGltYWdlLCB0aGUg
d2luZG93IHdpbGwgdXNlIGBpbWFnZS1kaXJlZC1pbWFnZS1tb2RlJw0Kd2hpY2ggaXMgYmFz
ZWQgb24gYGltYWdlLW1vZGUnLiINCiAgIChkZWNsYXJlIChhZHZlcnRpc2VkLWNhbGxpbmct
Y29udmVudGlvbiAoZmlsZSkgIjI5LjEiKSkNCiAgIChzZXRxIGZpbGUgKGV4cGFuZC1maWxl
LW5hbWUgZmlsZSkpDQogICAod2hlbiAobm90IChmaWxlLWV4aXN0cy1wIGZpbGUpKQ0KICAg
ICAoZXJyb3IgIk5vIHN1Y2ggZmlsZTogJXMiIGZpbGUpKQ0KICAgKGxldCogKChidWZmZXIg
KGdldC1idWZmZXItY3JlYXRlIGltYWdlLWRpcmVkLWRpc3BsYXktaW1hZ2UtYnVmZmVyKSkN
CgkgKHdpbmRvdyAoZ2V0LWJ1ZmZlci13aW5kb3cgYnVmZmVyKSkpDQogICAgIChmaW5kLWZp
bGUtbm9zZWxlY3QtMSBidWZmZXIgZmlsZSBuaWwgdCBuaWwgbmlsKQ0KICAgICAod2l0aC1j
dXJyZW50LWJ1ZmZlciBidWZmZXINCiAgICAgICAoaWYgKHN0cmluZy1tYXRjaCAoaW1hZ2Ut
ZmlsZS1uYW1lLXJlZ2V4cCkgZmlsZSkNCiAgICAgICAgICAgKGltYWdlLWRpcmVkLWltYWdl
LW1vZGUpDQogICAgICAgICA7OyBTdXBwb3J0IHZpc2l0aW5nIFBERiBmaWxlcy4NCiAgICAg
ICAgIChub3JtYWwtbW9kZSkpKQ0KDQogICAgICh1bmxlc3Mgd2luZG93DQoJKGRpc3BsYXkt
YnVmZmVyIGJ1ZmZlcikpKSkNCg0KaW5zdGVhZCBvZiBkb2luZyBhbGwgdGhhdCAna2lsbC1i
dWZmZXInICh3aGljaCBjb3VsZCBkZWxldGUgdGhlIHNlbGVjdGVkDQp3aW5kb3cgYXMgYSBz
aWRlLWVmZmVjdCBzbyB0aGUgZmluYWwgJ3NlbGVjdC13aW5kb3cnIHdpbGwgdGhyb3cgYW4N
CmVycm9yKSAncmVuYW1lLWJ1ZmZlcicgcmlnbWFyb2xlLg0KDQptYXJ0aW4NCg==




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at 74246 <at> debbugs.gnu.org:


Received: (at 74246) by debbugs.gnu.org; 9 Nov 2024 11:37:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 09 06:37:25 2024
Received: from localhost ([127.0.0.1]:53703 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t9jmO-0007po-OD
	for submit <at> debbugs.gnu.org; Sat, 09 Nov 2024 06:37:24 -0500
Received: from eggs.gnu.org ([209.51.188.92]:58198)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1t9jmN-0007pb-6D
 for 74246 <at> debbugs.gnu.org; Sat, 09 Nov 2024 06:37:24 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1t9jmG-0000F7-KR; Sat, 09 Nov 2024 06:37:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=+eIaiWuqM6Dpbn/NbT3hkVhiYd/RMx574qNiaY8cRGo=; b=C8Wqtpum2cFQ
 TW0Sc7MWdbpQFOWGfBxDx0PxbxNTtNIw9rGeZvVcoEWJtAY8v2bWYlo1ZBOguehGGLIYCCTCvcsji
 mvmY8OBRdQEEeoBTxlTUN+DVTsspKDJgne04OXSiJdWtfZ1sHYSB1Z4eGRM69p22RZaBSFrODhePl
 Ogsl+SKNcg+jdwy6Lk+VAbdF88ktGJ5ryRKc5sglLMJ8iYy1MCxVQIe5UBMfgOT43TI5COkSCTXOo
 4/oPpwoqp+QUTEhVwbT5NWplIjyL8/lkHJi8onaWtDJHH8wGUXEfqg9M3WH3HpFzNhNLRYCpABGzI
 mp8MSrYkY4F0rp3kF2RWiQ==;
Date: Sat, 09 Nov 2024 13:37:12 +0200
Message-Id: <868qtsmydz.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Morgan Smith <Morgan.J.Smith@HIDDEN>,
 martin rudalics <rudalics@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
 (message from Morgan Smith on Thu, 07 Nov 2024 15:19:15 -0500)
Subject: Re: bug#74246: [PATCH] Reuse display windows in image-dired
References: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 74246
Cc: 74246 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Morgan Smith <Morgan.J.Smith@HIDDEN>
> Date: Thu, 07 Nov 2024 15:19:15 -0500
> 
> When using image-dired, one can use SPC (image-dired-display-next)
> repeatedly to display successive images in a dedicated buffer.  However,
> it seems to choose a different window each time I press SPC.
> 
> I can reproduce this in "emacs -Q" when I have 4 windows.
> 
> The following patch works on my system.

Thanks.

Martin and Stefan, any comments or suggestions?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 7 Nov 2024 20:24:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 07 15:24:20 2024
Received: from localhost ([127.0.0.1]:49710 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t993D-0002A1-Io
	for submit <at> debbugs.gnu.org; Thu, 07 Nov 2024 15:24:20 -0500
Received: from lists.gnu.org ([209.51.188.17]:40170)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <Morgan.J.Smith@HIDDEN>) id 1t993B-00029t-KY
 for submit <at> debbugs.gnu.org; Thu, 07 Nov 2024 15:24:18 -0500
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 <Morgan.J.Smith@HIDDEN>)
 id 1t993B-0001Dg-Dz
 for bug-gnu-emacs@HIDDEN; Thu, 07 Nov 2024 15:24:17 -0500
Received: from mail-mw2nam10olkn20830.outbound.protection.outlook.com
 ([2a01:111:f403:2c12::830]
 helo=NAM10-MW2-obe.outbound.protection.outlook.com)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <Morgan.J.Smith@HIDDEN>)
 id 1t9939-00071Z-PP
 for bug-gnu-emacs@HIDDEN; Thu, 07 Nov 2024 15:24:17 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Pm9S+Q6CwQrfIlwyDpgHsMNpTXWijuzNaqZYVeZ3heYbbFHl4Ayvhz5gmcqjtYtUNV8dzRXKRhllhTU9ZWtWC0Eve4F9sMOT4ThDAZ2LVkkqbdjAOXZNzJOoMDa6cV/O5ImImcDUTOH4BLyFM25hxa84zC/aAfo1PPhgtDpoPYivBA+MTXedlVQY+nIpSZm8W8yj2+D2j+wCtkaVx+dd4Jf9yjuH5LgIe3Yt3YsBuw8OwylWx+TYkJ4CIojilMordUydWKYy0+ZaNNDvkFmHLXsyi0mRoQH/oHRBrVk1GWxzcKmflp8BcPUUVyY+9dIWXnaRRdPrJ/SOx677xA8wQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4b+/rRN6AOTh3dHcAY1oK6zsqIe3qvcAcXDVdrZlBnw=;
 b=m/rNOuEJrM+Tkn8aJ2k8601P6W9IWc5YFOf0XrfnSqwy8qT6rFp57/rxEnNdWy4ifXDIxJReSuqD4xRgxmqsi1F5d90yF7AUVCwuuuJxwLUMtnol6LGwb6afnhthKKffEf7GpBvMWJ/JVqoWDTUSXYIousySkbNd7boBBoZRJGmfjQmiiJwwOU9FdZjHV9KjM7FanmKNOgtiP0HJ+SAJKfZfiZgUKjdOf3WqSlQglYbrv2KSTR0QxPDwamvGe30buauLzVsNSJN9UcWHDGmb7FGeVl+yVnP6LMNkI3ljUBC+rY3awzJd8gZ91KOFRoxxl7IAIGxJ/+aAecef8dN/Vw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4b+/rRN6AOTh3dHcAY1oK6zsqIe3qvcAcXDVdrZlBnw=;
 b=W2eX11r56KdsHAjud3pgM9PafBY5dE9rc0Nx+VueqoiMp0c/mdMjzmUU1hSHOYAtS4QBNMnvBVsYuBQ7Ei42HGQJHRrypmMyS5AGPmd5234dv5x+d86m4T+WaNJRFOExcBGY+A8uU+DzLvZPj4mOXiTsFdyJuyce6vCqJERctrQSVy4hdhAZuznlhsB/I+yVoW6O13xLRjgYtHb5a4aupDzprDgwJ0Yy8h61pfIl5/mSPXU0SlR6AmG94s4PCP9Ffo3LW8fRAYqsWp2kJnBlwI+E63cM5nHKuoBYzDlZgiOW72aS5FexJOZTVyYCral2VwX98TVBYNc7smD0Grwxdg==
Received: from CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:610:1c4::17)
 by MN0PR84MB3915.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:208:4c9::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8137.19; Thu, 7 Nov
 2024 20:19:05 +0000
Received: from CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM
 ([fe80::5c77:7a58:48ed:9aef]) by CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM
 ([fe80::5c77:7a58:48ed:9aef%3]) with mapi id 15.20.8137.018; Thu, 7 Nov 2024
 20:19:05 +0000
From: Morgan Smith <Morgan.J.Smith@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] Reuse display windows in image-dired
X-Hashcash: 1:20:241107:bug-gnu-emacs@HIDDEN::LrAp8fK8QK008asY:Qze
Date: Thu, 07 Nov 2024 15:19:15 -0500
Message-ID: <CH3PR84MB3424D9B5D11B35E8CA3637FFC55C2@HIDDEN>
Content-Type: multipart/mixed; boundary="=-=-="
X-ClientProxiedBy: MA2P292CA0014.ESPP292.PROD.OUTLOOK.COM
 (2603:10a6:250:1::10) To CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM
 (2603:10b6:610:1c4::17)
X-Microsoft-Original-Message-ID: <871pzmlruk.fsf@HIDDEN>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PR84MB3424:EE_|MN0PR84MB3915:EE_
X-MS-Office365-Filtering-Correlation-Id: 6f27ec8c-b8d8-4d41-9f93-08dcff696cf1
X-Microsoft-Antispam: BCL:0;
 ARA:14566002|8060799006|6092099012|5072599009|19110799003|15080799006|7092599003|461199028|13095399003|3412199025|440099028;
X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?7vlyiVHRTv4dUzC4caqvwvtJC1D+WTNpPEzM6QJHJ6pB5P4WQaG/30nMa3+X?=
 =?us-ascii?Q?GGf3PbeWzNrR0qmvTww5MLGGHPvyAVzzJwMCmHjeN5sQngOx2/vCBocl/YIY?=
 =?us-ascii?Q?3PhBO51Rkve06osMNb0uq+r5kXtLQZbzB6Q+IdRcJniPP81jld4FoUjkockJ?=
 =?us-ascii?Q?UHKPZbBzRzccosGK8JgK9jvbmpFmOPwo8+A89QiGW1BbMjq5REkdM8G0GZr9?=
 =?us-ascii?Q?NsY558olDBGUK930bRfryfq/bIRRALkpHOf63optyfZ6Lu73sH02/sGRCOP2?=
 =?us-ascii?Q?IZiLY5OR/fZrE5bSoGG2zeqplng1k0zlz4lQUvcuNmoUUqzlUhWkenyHheCa?=
 =?us-ascii?Q?VXz372Jj8xcHX5R8Uhl322sYXg3K2sMpYW24SscXBpLolA7UkejukMcCUIwz?=
 =?us-ascii?Q?EiY2wQusCYmnffmWadXzLoksJXg8i3WkDJLnMir05K9pjGxoFE+hZs1FSCsv?=
 =?us-ascii?Q?jr10jHpWx4yEcRGe9BHbDVknbPafPA3lcp4eHZO7o3knCkNYU5hDG6ReMSE3?=
 =?us-ascii?Q?dOCov87SonxT85GzYBLJT3koh9ol2VeXaoVqYSXXhYGunYcqiZbk92tSHEtj?=
 =?us-ascii?Q?CbkPilh9T9SV5Sa08NwTnFHid6CL7yVAtrxQ6dgTH//MH5GDaEjyxogtXTyw?=
 =?us-ascii?Q?EbN2ZI/gUwu6xhXmPZdSESRptLwOLFxM9p1okodeCP6IDDLxUiJtUqx92UhU?=
 =?us-ascii?Q?X8QVWkm9dM/I+mdlEU4sOuupfxpC9Zxjo4ZtGW8sTwnHjDAX07wvw+MIQq25?=
 =?us-ascii?Q?mAeMjvx+xk6TnLMgfAfaRa8X/00QCUkHHFLeweVDTeyVSlV9fV+r44RHPDWs?=
 =?us-ascii?Q?1igzo+5GASD3vxEKXVmT93Ut9h5dtxqmJdt40N9V9hx/IjyrpYPGsTYkVrxY?=
 =?us-ascii?Q?VJT9zgIdOdguq/Fhyv22P1eD2jBCcnxBC9ZqHkgUcWGyqAITUA8rg00PFb6o?=
 =?us-ascii?Q?iK6R/biKfHKZ50t9D+/j68eTMKIGx3xpJifeeQ6MWWf3xyxGrlyCQ8zf7Wfp?=
 =?us-ascii?Q?dT71GsuiKaurbpVlXS7liCmzFJ3n5iB0AqSuxD9tN5k8seYOSOQMLZjq3QrO?=
 =?us-ascii?Q?/D+ZRQb3w6L0Je10QbxdC45vPJ9K/injb3MmkpsNhsAeFoX42WQ=3D?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tRsPCytWW2lgRxRRuKxWwHQfE5orKmGEYC08BWPpCZeXxLdnqlnMwPtm10rv?=
 =?us-ascii?Q?CKW4Wu07m0vAX1b2xVxGyYTa6RS/7EP90kd6k5JB8mRia7Viqi+MZad6oJcu?=
 =?us-ascii?Q?aW5igLMWhWrpCWj6qHM2uskY0WKakO3NMrLZ0SW/D0bZYn/tmpH7CMRYlRXn?=
 =?us-ascii?Q?HagLWIlyn6qpsbeCoZopCcE2PxNKKRhGoeOa64PbGZMgtdBMvFwneaJPVpBB?=
 =?us-ascii?Q?WSJLQ9FqCFcxdzYNn7IfsVqqFULSgwdLdujvscX6u6uk90h+0AnnhcV47vzt?=
 =?us-ascii?Q?zVhbKVzdgfV140sU+jF+UEmcPSYDidBKr+QAa0Ld9RgclHSyb8VUsKZCePmJ?=
 =?us-ascii?Q?HoCSG4pOpxqflElHboJitHM0A6Njp/04vCHi++80kL8mWwdHTsLZwiUCkNN1?=
 =?us-ascii?Q?8Ac0052nEyIbMVVcuNHar0ra0dKWAJYTSYQOvkM5Q/UGDFt5mmTKMV4RruPx?=
 =?us-ascii?Q?+3zPMnviCuMTMbdfNJJl3O3DvoINAnvShfKoHqrVGnfgljbVGAzYalhM0Yam?=
 =?us-ascii?Q?O0jBD3itad8a51whm/UHdD0mrDMpsXvBBR1biD7N46f5aonR6Dg2G//u6LJ2?=
 =?us-ascii?Q?B6AcjkJitUC4VJO/kAcOIK/mechGG93a0sIF0KnQfo3Jtgd4qU4Il8kVG1dt?=
 =?us-ascii?Q?OIhTktpvdkzRQL/yJXWkKwtinmHqrnjHvbpkERRyrqoKiUinSt2O5EUq7xti?=
 =?us-ascii?Q?9bMBsKEglQo3cPMAg0Cutk9pMj5dsNSDET3ui3k+i6tOjx3sSuW1evijyD7d?=
 =?us-ascii?Q?II3l/HYbTpXVIqJVGKT0b9bNFDhh2FK7Zp5RjVa5hnadd/Lk35VNaNQNrAYd?=
 =?us-ascii?Q?TjBQ2hPepTPc6TOM9CBuKQtmWghYhwdyWo/Jib/8GxR6aAuP9trSrR88VnTS?=
 =?us-ascii?Q?rFdPnOLj7oR4EX7xgOJeFhVGkGVS4TvsqoghodsWJFylb0G+xHqpCbfEaDd/?=
 =?us-ascii?Q?vncu+SqGzGxhsQ6Sn1Syt1eKn0tH0Zdy6OmELW3NxTiKd3tieuYxfFhMgamO?=
 =?us-ascii?Q?J5TeFzcAUS548t9Dnqc0+vp3j5FnQ0NAb70v3JtcNxfrdP8zo8lpF7qPzZw2?=
 =?us-ascii?Q?vK+xNAWeXWESki8+PmWe7NNyJx1M1htmH1O3ch+Bcs8KlJdXgt3nQXcdXUVe?=
 =?us-ascii?Q?lxLUpBbQ0/Gx4GCWTh4ohv8FQaLTcvAHyPakr+3GikN+X4zU/7GX/IE/Xszi?=
 =?us-ascii?Q?zharEChPsL5nwROzjD8jH2HJiGVQqPggq4DUWHcV+gqiv5ujAxry1gWH4QrR?=
 =?us-ascii?Q?teaMLPfpvgZfsH9arR55?=
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f27ec8c-b8d8-4d41-9f93-08dcff696cf1
X-MS-Exchange-CrossTenant-AuthSource: CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2024 20:19:04.9877 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR84MB3915
Received-SPF: pass client-ip=2a01:111:f403:2c12::830;
 envelope-from=Morgan.J.Smith@HIDDEN;
 helo=NAM10-MW2-obe.outbound.protection.outlook.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--=-=-=
Content-Type: text/plain

Tags: patch

Hello,

When using image-dired, one can use SPC (image-dired-display-next)
repeatedly to display successive images in a dedicated buffer.  However,
it seems to choose a different window each time I press SPC.

I can reproduce this in "emacs -Q" when I have 4 windows.

The following patch works on my system.

Thanks,

Morgan

In GNU Emacs 30.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0)
System Description: Guix System

Configured using:
 'configure
CONFIG_SHELL=/gnu/store/3jhfhxdf6v5ms10x5zmnl166dh3yhbr1-bash-minimal-5.1.16/bin/bash
SHELL=/gnu/store/3jhfhxdf6v5ms10x5zmnl166dh3yhbr1-bash-minimal-5.1.16/bin/bash
--prefix=/gnu/store/9x5277gcjzwlis5yd0iq7ypq8f78jhpa-emacs-next-pgtk-30.0.91-1.9a1c76b
--enable-fast-install --with-pgtk --with-cairo --with-modules
--with-native-compilation=aot --disable-build-details'


--=-=-=
Content-Type: text/patch
Content-Disposition: attachment;
 filename=0001-Reuse-display-windows-in-image-dired.patch

From a02b37cbcdbee4c773336a82f2109b1c03467107 Mon Sep 17 00:00:00 2001
From: Morgan Smith <Morgan.J.Smith@HIDDEN>
Date: Thu, 7 Nov 2024 14:24:01 -0500
Subject: [PATCH] Reuse display windows in image-dired

* lisp/image/image-dired.el(image-dired-display-image): Reuse
the windows used by the previous buffer.
---
 lisp/image/image-dired.el | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lisp/image/image-dired.el b/lisp/image/image-dired.el
index 1928b0a2955..37f23665755 100644
--- a/lisp/image/image-dired.el
+++ b/lisp/image/image-dired.el
@@ -1268,11 +1268,15 @@ image-dired-display-image
   (setq file (expand-file-name file))
   (when (not (file-exists-p file))
     (error "No such file: %s" file))
-  (let ((buf (get-buffer image-dired-display-image-buffer))
-        (cur-win (selected-window)))
+  (let* ((buf (get-buffer image-dired-display-image-buffer))
+         (windows (and buf
+                       (get-buffer-window-list buf t t)))
+         (cur-win (selected-window)))
     (when buf
       (kill-buffer buf))
     (when-let ((buf (find-file-noselect file nil t)))
+      (dolist (window windows)
+        (set-window-buffer window buf))
       (pop-to-buffer buf)
       (rename-buffer image-dired-display-image-buffer)
       (if (string-match (image-file-name-regexp) file)
-- 
2.46.0


--=-=-=--




Acknowledgement sent to Morgan Smith <Morgan.J.Smith@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#74246; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 12 Jan 2025 05:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.