From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.orgmode,gmane.emacs.devel Subject: Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers? Date: Thu, 19 Dec 2024 17:47:13 +0000 Message-ID: <87cyhn7efy.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11379"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , =?utf-8?Q?S=C3=A9bastien?= Gendre , Org Mode List , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Thu Dec 19 18:46:45 2024 Return-path: Envelope-to: geo-emacs-orgmode@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tOKbk-0002me-5H for geo-emacs-orgmode@m.gmane-mx.org; Thu, 19 Dec 2024 18:46:45 +0100 Original-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 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOKan-0006EE-Ln for emacs-orgmode@gnu.org; Thu, 19 Dec 2024 12:45:47 -0500 Original-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 Original-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== Original-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) In-Reply-To: <4a276720-259e-458a-a0ea-53cdd24e8ee6@gmx.at> 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+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Original-Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.orgmode:164249 gmane.emacs.devel:326756 Archived-At: 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