From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 2O2ZEwRcZGc7JwEAqHPOHw:P1 (envelope-from ) for ; Thu, 19 Dec 2024 17:46:44 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 2O2ZEwRcZGc7JwEAqHPOHw (envelope-from ) for ; Thu, 19 Dec 2024 18:46:44 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=oLlmDp9c; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1734630404; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=2Jp+4NPWfttlzwcx8MPIXRvvgAv3KNDOlo5Lwop2NZk=; b=PNe/BGgRY5i3hkGj4jKSwpNL/fAF/Q7Sb63EzVUGt+ZM57dzHB6twLZLjZ/Mh+xmu20c2f MelKL9uFK/ngzBOWPa1AZOBF3Q0eWRyz+ImuY6U0XyPjzYofZ4udIfj8ETq/L4VkSN4Ko6 TFJK3Eyy7IdhsS8JRpUnUFXIJFY1a/bt+F++RtKyoRjVf77w8jjnwLb9Am4w4Mk2vHMAJb euiOaftGkrCv7JuiGjMgDwnkZXEh0YRqal0tNYP36p+kDBnWUghlWQnm9BFH71/mp7tzTW 241iS8k5rUcwXnMFDhct6Rt2/wi3cnyIAVRr6a/AiIxSDLwvH1owvkkksFZOvA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=oLlmDp9c; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1734630404; a=rsa-sha256; cv=none; b=ZFfuQp0114YZFLlQAnEbAloWCbkFWzb9leNfBJXfAH7leo2fx9UaaxXgf2gqx9ye9hCShw 3BNbfSzzzgzB24XGkoFAR22i2mekQaoFyNy9bxGxkyNDZcQ5zWj6VI2mHyyy0mfCPczCcS QlxsTeEFPbhG7n09FG3r+m7Cie0lGKiBp3NShPMNNe9snOUJeH08qXYmDwPcVu+OrLi0R4 jNFXFpr+37At/mxl9I+ntIeUCyf6D+s9K0l3jFI5tsJCoIK1u9SeprvfmFEzMat+Nz+nBq /DKFBsjEiytxPSXEZiKccwu4GPsOtkLs3ulRRzh/XyojWuUUFzLHW5rsUkw0gg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E76425E3E4 for ; Thu, 19 Dec 2024 18:46:43 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOKav-0006Lo-3K; Thu, 19 Dec 2024 12:45:53 -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 ) id 1tOKan-0006EE-Ln for emacs-orgmode@gnu.org; Thu, 19 Dec 2024 12:45:47 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOKak-00036Z-72 for emacs-orgmode@gnu.org; Thu, 19 Dec 2024 12:45:43 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 3B476240103 for ; Thu, 19 Dec 2024 18:45:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1734630339; bh=NsL9xd7UjYdpBTuJO4hillqLwd+y36+LVC7OU40DvKg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=oLlmDp9c76xCYwYUNyO7ELOdZdk3S8twa1ohsACzTdKFM8zXeCmtMdaptGerqxeDW 2RHtEtZp1NdjGMssbyLnH+4OXeCMJ709rYDOoPw+fxYZNF9kSxV0hHlN5CB6rk+Gee Kh5sOUS40GyMlxxZaQ5OzhZA7SeV9LTBBkALSz2b5CbpGOrZUOoiMjTIpQVImhnPym FIkqRlrP3vtXCpHqYstYvngT8aHyJRY7uasT9gv8vk8DC667kXXrjglQ3nVY8y2BMq OUkKn5zrgLm5FnVcF7S5rwhjll3CEqwrdNzwi32GFU3wCWSwFiGVLL4qLE1OMPIiZX BT4QW18bMw5kg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YDdHk39Fzz9rxM; Thu, 19 Dec 2024 18:45:38 +0100 (CET) From: Ihor Radchenko To: martin rudalics Cc: Juri Linkov , =?utf-8?Q?S=C3=A9bastien?= Gendre , Org Mode List , emacs-devel@gnu.org Subject: Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers? In-Reply-To: <4a276720-259e-458a-a0ea-53cdd24e8ee6@gmx.at> References: <878qtycdmi.fsf@k-7.ch> <87msgx7yo5.fsf@localhost> <87ttb42i1b.fsf@mail.linkov.net> <87r067cxi6.fsf@localhost> <87y10e6uyf.fsf@localhost> <9d81cb95-8d46-4c51-8daa-d7c8fb44413a@gmx.at> <87o7187t44.fsf@localhost> <4a276720-259e-458a-a0ea-53cdd24e8ee6@gmx.at> Date: Thu, 19 Dec 2024 17:47:13 +0000 Message-ID: <87cyhn7efy.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: 0.67 X-Spam-Score: 0.67 X-Migadu-Queue-Id: E76425E3E4 X-TUID: k+kHjD+HxI8U martin rudalics writes: > > It seems to work, although somewhat different than I described. > > > > With your diff, in case (2), if BUFFER is what is passed to > > `pop-to-buffer' and BUFFER2 is indirectly related buffer displayed in a > > visible window, then BUFFER2 is replaced with BUFFER. I expected that > > BUFFER2's window will be selected; nothing more. > > Hmmm... This is not really what 'display-buffer' is supposed to do. I > have to disguise the fact that we wanted to display BUFFER. I attach a > new patch. Now, when you said that, it does feel not right indeed. What I was concerned about is the situation my request originated from: 1. Org displays a *narrowed* indirect buffer 2. User requests to jump to a heading in base buffer of that indirect buffer 3. Changing the buffer (even in the same window - with your patch) will suddenly change the narrowing state. That said, it is not a problem `display-buffer' is supposed to solve anyway. The modified `get-buffer-window-list' from your patch may also be used in the above scenario before deciding which buffer we want to change to. So, I'd myself vote for the first version of the patch if looking from more general Emacs perspective. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at