From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id GBStIVbBIGCTBQAA0tVLHw (envelope-from ) for ; Mon, 08 Feb 2021 04:43:02 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id qCl/HVbBIGBYEgAAbx9fmQ (envelope-from ) for ; Mon, 08 Feb 2021 04:43:02 +0000 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 060A994029C for ; Mon, 8 Feb 2021 04:43:01 +0000 (UTC) Received: from localhost ([::1]:45046 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8yO4-0002OB-Fd for larch@yhetil.org; Sun, 07 Feb 2021 23:43:00 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47496) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8yNL-0002O1-Hn for emacs-orgmode@gnu.org; Sun, 07 Feb 2021 23:42:15 -0500 Received: from out1.migadu.com ([2001:41d0:2:863f::]:51066) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8yNE-000297-Lk for emacs-orgmode@gnu.org; Sun, 07 Feb 2021 23:42:15 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1612759322; h=from:from: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; bh=eWF7RmI6E/n4E1ox2UaFR3qKWJyl/8GlR5yso/2J8rw=; b=G7wsDRmq5tvf3aFXtOnhPPdZ8tSzs4VwAdiVAEt7HO0Ez3UI0Zd47qzufTZgYjFJxtFqMC K4UDuhhYHFHgqrgMJO6G/qKTBDZsnJfyukIf6PJ1itJaq5niI36+pTQGe02z4aiYxV5IIa iL4oNRe1bssYMLK3RwxMbPqql5gOrCKDRVHlodOdqgU3OIeWqoTmPZNCxzK/6WAclZK2f0 VOoBG5eXDkBPkC5qDg35xNTnnmYaKHNTHavjsfzqdWk/PFUWJBValce9lVZ4jBqGOnlAW7 o2TIBDxPDfoM2Dj30u2RxOgPRtXLGguztRpn6gda1XumsEsrCZ2R8nGgJbKALQ== From: Kyle Meyer To: "Joshua O'Connor" Subject: Re: org-no-popups nilling display-buffer-alist In-Reply-To: <87eehtwohk.fsf@joshuao.com> References: <87eehtwohk.fsf@joshuao.com> Date: Sun, 07 Feb 2021 23:42:01 -0500 Message-ID: <87k0rjxjae.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Auth-User: kyle@kyleam.com Received-SPF: pass client-ip=2001:41d0:2:863f::; envelope-from=kyle@kyleam.com; helo=out1.migadu.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.56 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=kyleam.com header.s=key1 header.b=G7wsDRmq; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 060A994029C X-Spam-Score: -2.56 X-Migadu-Scanner: scn0.migadu.com X-TUID: XyAouuTS20Ji \"Joshua O'Connor\" writes: > Hi, > I wanted to control the positioning of the *Org Select* buffer, so I > first went to add a rule to 'display-buffer-alist'. > But I found it didn't work, as the function in question calls > 'org-switch-to-buffer-other-window', which in turn calls an odd macro > 'org-no-popups', which appears to let-nil the 'display-buffer-alist'. > > I was wondering what the reason is for this? To me I expected this > variable to be reserved for me as a user to choose where windows can go, > which I think is a good plan given that you cannot possible know all the > configurations a user may want the window to appear. I agree that this should left to the user, and in 9.4 there was at least some progress in making Org behave better in this department: . I've yet to do any extensive digging, but I suspect there wasn't a strong reason for doing this. I'd be in favor of a patch that drops the use of display-buffer-alist.