From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id cJcZG5RSaGH1RwEAgWs5BA (envelope-from ) for ; Thu, 14 Oct 2021 17:53:56 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id WKvbFpRSaGEKXQAA1q6Kng (envelope-from ) for ; Thu, 14 Oct 2021 15:53:56 +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 B0AA122189 for ; Thu, 14 Oct 2021 17:53:55 +0200 (CEST) Received: from localhost ([::1]:40422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mb33J-0000tI-6M for larch@yhetil.org; Thu, 14 Oct 2021 11:53:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mb2ur-00016N-2s for emacs-orgmode@gnu.org; Thu, 14 Oct 2021 11:45:09 -0400 Received: from ciao.gmane.io ([116.202.254.214]:40300) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mb2up-0004jb-Bd for emacs-orgmode@gnu.org; Thu, 14 Oct 2021 11:45:08 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mb2un-000AUy-7I for emacs-orgmode@gnu.org; Thu, 14 Oct 2021 17:45:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken Date: Thu, 14 Oct 2021 22:44:55 +0700 Message-ID: References: <87mtnovv7f.fsf@alphapapa.net> <87h7dvy70t.fsf@localhost> <87ee8zxwic.fsf@localhost> <878rz3ddet.fsf@gmail.com> <87czoaug5x.fsf@gmail.com> <87o87tso54.fsf@localhost> <87pms9mf7v.fsf@gmail.com> <878ryx14sd.fsf@ucl.ac.uk> <87fst46ifa.fsf@gmail.com> <87h7djdi7k.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <87h7djdi7k.fsf@localhost> Content-Language: en-US Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1634226836; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=Ec1FT+6xKOJNaUaJk526VUlTd9atUzelaVegtLofxdk=; b=rYrxj2xk2z7Ppu7SK2vH2znxND8iVz2qR3zM3bP4578l9uMKwIHKgiVCg98KsZd+6+md2s kVNp0ssnVFDYzRaPwcePCV2EOYN2vw19fezG4k1bYixWy69F7yxnRwS9j1PrEesogoaDzS cis2AHgsalijlWNBvD/ePtnk9ooJbOqeF6GKDyMrXAkd4nDpjRW8eBNPniCDJqGjGVSubi 8jSUIntNabS6qSNf8CvlHnmOB4TSkx+h+k8uAQqkLMYkC4oWZN933QA8blbi2yCzKxapYI skq5d5wdTMcsbETUCtw7W2pDEEzavzNiPorbRjjfDNJE33g9KQK1CUN2skcNOQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1634226836; a=rsa-sha256; cv=none; b=Eq2fm8qIXjpE3lkevNMGTZxZN0b3mhm66u71RylX2nzHADB0YQ8MQZ0HrKJ5SrLrQwlLvT cUTiXKg2rtVMpsyCKDpXvUtv8IDcoFilJ5PCoD+O+fqEg52cW+tyKbrj5T1qp8ZMAP53+A OMK7zsPwpME1lNfryw0gBFRqm/QRqQfsxsGwuh2UGxOsTA0jrRD2pkxdWYyzekxJAPWk7y lU/WPBAeXkw8E2ibXf2fb6cvyk+xacp/OuyLh+3G7A3kdGbI1Y/cQuNRdGZdcZKccpLt5T qjDVT7HwHvXSwW+esb3TMd/8j/UhrbcGAvYeH1uuo9b+aDsDMfTCTWgkLF59Kg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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-Spam-Score: -1.81 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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: B0AA122189 X-Spam-Score: -1.81 X-Migadu-Scanner: scn0.migadu.com X-TUID: LTAxOqKJor7p On 14/10/2021 17:16, Ihor Radchenko wrote: > Marco Wahl writes: > >> Since org-goto in main is still broken I'll commit the fix for org-goto >> which kicks out the use of the macro org-no-popups (but not the macro >> itself since it's used elsewhere AFAICS.) >> >> Max, Ihor! If you see the necessity of refinement please keep going! > > I am inclined to think that org-no-popups may still be useful to > suppress pop-up-frames. However, no so much for pop-up-windows. Note > that I introduced pop-up-windows let-binding in org-no-popups in place > of overriding display-buffer-alist. However, I did not fully understand > pop-up-windows does and the current let-binding actually changes > pop-up-windows value to nil (t is the Emacs default). I think we can > simply remove pop-up-windows binding from org-no-popups. Feel free to > commit this change. I am currently working on org-element-cache and do > not spend much time on other patches. Today I am against dropping of `org-no-popups'. Since Ihor confirmed that he had no particular reason to add `pop-up-windows', the minimal change (that should be applied to the bugfix branch) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 52fc09a06..5f2c29c42 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -209,7 +209,7 @@ because otherwise all these markers will point to nowhere." (defmacro org-no-popups (&rest body) "Suppress popup windows and evaluate BODY." - `(let (pop-up-frames pop-up-windows) + `(let (pop-up-frames) ,@body)) ^L I think, something should be done with `org-no-popups'. Assume a user who has (I have no idea concerning the goal though) (setq pop-up-frames t) (setq display-buffer-base-action '((display-buffer-reuse-window display-buffer-pop-up-frame) (reusable-frames . 0))) e.g. https://list.orgmode.org/20200503033854.GA28741@singpolyma-beefy With "emacs -Q" and above settings completion e.g. for "C-h f" does not cause creation of a new frame. Org help windows appear in new frames though. That is why `org-no-popups' should have more code. Minimal patch works in the cases like https://list.orgmode.org/87h7ij12t8.fsf@localhost and the one raised in this thread. I hope it will not break https://list.orgmode.org/orgmode/871rdtupey.fsf@joshuao.com/T/#u as well. In the meanwhile I found the following thread on window creation in Org and `display-buffer' machinery (accessibility concerns were mentioned besides other things): https://list.orgmode.org/87eevw7jqk.fsf@gmail.com/T/#u Jack Kamm. [RFC PATCH] Changes to pop-up source buffers. 2020-01-18 17:33 Unfortunately info "(elisp) Displaying Buffers" https://www.gnu.org/software/emacs/manual/html_node/elisp/Displaying-Buffers.html is a reference rather than a guide. I have not realized when `pop-up-frames' or its modern equivalent can be convenient. I have not tried Eric's setup yet. >> BTW I think the name *Org Help* for the UI buffer could be better. > > Do you have better ideas? Maybe something like *Org-goto Help*? If we > want to change it, we may want to do it now, before users actually use > *Org Help* name i.e. in display-buffer-alist. display-buffer-alist did > not affect *Org Help* before 399481bad, so we have low odds to break > anybody's config yet. Are there use cases when "*Org Help*" is not specific enough and more than one help window should be shown simultaneously or they should be shown in different sides? P.S. Example of complex window setup unrelated to Org: info "(elisp) Frame Layouts with Side Windows" https://www.gnu.org/software/emacs/manual/html_node/elisp/Frame-Layouts-with-Side-Windows.html