From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id vayVKlwRkmFK7gAAgWs5BA (envelope-from ) for ; Mon, 15 Nov 2021 08:50:52 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id CC+KJVwRkmGZCQAAbx9fmQ (envelope-from ) for ; Mon, 15 Nov 2021 07:50:52 +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 38AB912AD8 for ; Mon, 15 Nov 2021 08:50:52 +0100 (CET) Received: from localhost ([::1]:48262 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mmWlP-0005P2-3s for larch@yhetil.org; Mon, 15 Nov 2021 02:50:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mmWka-0005Od-4Z for emacs-orgmode@gnu.org; Mon, 15 Nov 2021 02:50:00 -0500 Received: from [2a01:488:66:1000:2ea3:4d27:0:1] (port=34408 helo=thenybble.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mmWkX-0005ri-V9 for emacs-orgmode@gnu.org; Mon, 15 Nov 2021 02:49:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thenybble.de; s=two; h=In-Reply-To:From:References:To:Subject:MIME-Version: Date:Message-ID:Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=naQbBZ8QIjwOmcCb8to/TRlyN/rwqgR7EEFv6Mqzq1g=; b=j+Ypf5y4i1bnmBekQWfe3r62tO dK82CAULWTqFcIBWKlUUaxWN/QpdcmZ6sYuyZ9pVQ1gevfdgH/eRlZvRaMl7zHW2H/6fCcd6DtQ/J 3NhboD9CU+l15OHq0SHGWbJj7H4hZSzC2BMvFHYquL9r04B4pO18e7/IfRF9xgul2i4E=; Received: from [2001:16b8:2db2:9400:c4e8:f620:9819:2089] by thenybble.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mmWkW-0007Tx-Jw for emacs-orgmode@gnu.org; Mon, 15 Nov 2021 08:49:56 +0100 Content-Type: multipart/alternative; boundary="------------Jhc1SQnp50oAw20oahbBjpUt" Message-ID: <893749f7-a709-674f-fe89-03574523396f@thenybble.de> Date: Mon, 15 Nov 2021 08:49:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Bug: org-no-popups disregards display-buffer-fallback-action 9.4.6 Content-Language: en-US To: emacs-orgmode@gnu.org References: <87a6ic5u1c.fsf@dumper.i-did-not-set--mail-host-address--so-tickle-me> <06bed7f3-4f31-4d66-4314-18c08c8dbb34@gmail.com> In-Reply-To: <06bed7f3-4f31-4d66-4314-18c08c8dbb34@gmail.com> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a01:488:66:1000:2ea3:4d27:0:1 (failed) Received-SPF: permerror client-ip=2a01:488:66:1000:2ea3:4d27:0:1; envelope-from=jan.seeger@thenybble.de; helo=thenybble.de X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-2.278, RDNS_NONE=0.793, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01 autolearn=ham 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" Reply-to: Jan Seeger From: Jan Seeger via "General discussions about Org-mode." X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1636962652; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=naQbBZ8QIjwOmcCb8to/TRlyN/rwqgR7EEFv6Mqzq1g=; b=n2aIbwqnpCI5/Dq48Wt9Pq2j0EGEP2btS9YNmRGHKl/038fV/CdNzLG3UvRYmT7ZcTnQV+ RjuSZCKQum1anlX4Vdszs+QGpZknqrv1+XCHIZsnJDOX0nPiGb/Ry2hRtEpvKhtvJLo3ni T42Rv+ACF0nUn2pImy9E5aZPD54T2mYa3XiAC+S5olua+RhyGaHR+ZKiX1NATaOqCWDMn3 jG4BuKa+v3JZ/b52927ezlRGd96B60U7mY7t2uQdECI8dzcdEmPU4OGX3DsFCTHfQKh2t0 Q9wFoBm9CQGS6+0P730vaDFr0gzvl/lEdi8D+wmVDyVH77TFE7s1gHMgjdiAbA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1636962652; a=rsa-sha256; cv=none; b=Tom4xwOvyBHtQftsXOHzra/KwjZpYahesMn9vDPYDIXh78/UFMybYZhQpC17C4KqQS12oC +jaRsu5zn6d8lnm4Nkt6dhYZsDcMJ72wjKOAUeerz/tJJ2yN6XHd9Nd8dyhvdDvZ//bIjq MEOZelWuoc+eM3qb7MnhkarMwkv3zTWJpbVPikd7aE1i7h9hP7WZshu8HPdZyRi8T91kVy T3fxQnLK5F29BEV2K+pUFg0nyA9hqapaFpc+EKCLZFR0+6gvEW/n8iwM7atwJYSdIlQhzo K5Mmxha5ty421+JkWa+QppYPsSYuiDoHfcSRm3+wnBTPbBO6cc0ysp909KYNkQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=thenybble.de header.s=two header.b=j+Ypf5y4; 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" X-Migadu-Spam-Score: -1.84 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=thenybble.de header.s=two header.b=j+Ypf5y4; 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" X-Migadu-Queue-Id: 38AB912AD8 X-Spam-Score: -1.84 X-Migadu-Scanner: scn0.migadu.com X-TUID: gChyJmr3CY0I This is a multi-part message in MIME format. --------------Jhc1SQnp50oAw20oahbBjpUt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello! On 13.11.21 14:15, Max Nikulin wrote: > Some users prefers multiple frames, others multiple windows in a full-screen frame. Could you, please, briefly describe what kind of behavior you are truing to achieve? My thought is that I have a perfectly good window manager that allows me to manage Emacs frames. This removes the need for things to improve window switching (such as winner, which I used previously). Popping up frames to show multiple things at the same time integrates well with my WM, and doesn't force me to remap things like `C-x o`, which I find cumbersome to use. There are packages that make window switching easier, but I've already configured my window manager. Thus, I prefer to have my window manager manage Emacs frames, instead of adding yet another way to switch between multiple things being displayed at the same time, which I would have to do using Emacs windows. My current configuration is as follows: (setq display-buffer-base-action '((display-buffer-reuse-window display-buffer-pop-up-frame)                                    (reusable-frames . 0))) (setq display-buffer-alist       `(("\\*Packages\\*" display-buffer-pop-up-frame)         ("\\*stdin.*\\*" display-buffer-same-window)         ("\\*Help\\*" display-buffer-pop-up-frame)         ("\\*.*\\*" display-buffer-pop-up-window))) This allows me to pop up normal frames for regular buffers, and have special buffers pop up in windows to fix the "focus stealing" behavior mentioned above. The central problem with popping up frames is focus stealing: Things such as undo-tree or embark don't deal well with having the focus stolen from the current buffer by a new frame, which is why I needed to configure `display-buffer-alist`. > Some Org buffers, in my opinion, should behave similarly to completion list. On the other hand `minibuffer-completion-help' does not use `display-buffer-overrining-action'. I do not like that this variable has higher priority than `display-buffer-alist'. Action argument of `display-buffer' is more appropriate since it keeps ability to customize placement of buffers with particular names through `display-buffer-alist'. I don't fully understand the `display-buffer-alist` definition, and copied mostly from the documentation examples. I hope this helps. Best regards, Jan PS: Sorry for the empty mail I sent previously. --------------Jhc1SQnp50oAw20oahbBjpUt Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello!

On 13.11.21 14:15, Max Nikulin wrote:
Some users prefers multiple frames, others multiple windows in a full-screen frame. Could you, please, briefly describe what kind of behavior you are truing to achieve?

My thought is that I have a perfectly good window manager that allows me to manage Emacs frames. This removes the need for things to improve window switching (such as winner, which I used previously). Popping up frames to show multiple things at the same time integrates well with my WM, and doesn't force me to remap things like `C-x o`, which I find cumbersome to use. There are packages that make window switching easier, but I've already configured my window manager. Thus, I prefer to have my window manager manage Emacs frames, instead of adding yet another way to switch between multiple things being displayed at the same time, which I would have to do using Emacs windows.

My current configuration is as follows:

(setq display-buffer-base-action '((display-buffer-reuse-window display-buffer-pop-up-frame)
                                   (reusable-frames . 0)))
(setq display-buffer-alist
      `(("\\*Packages\\*" display-buffer-pop-up-frame)
        ("\\*stdin.*\\*" display-buffer-same-window)
        ("\\*Help\\*" display-buffer-pop-up-frame)
        ("\\*.*\\*" display-buffer-pop-up-window)))
This allows me to pop up normal frames for regular buffers, and have special buffers pop up in windows to fix the "focus stealing" behavior mentioned above.

The central problem with popping up frames is focus stealing: Things such as undo-tree or embark don't deal well with having the focus stolen from the current buffer by a new frame, which is why I needed to configure `display-buffer-alist`.

Some Org buffers, in my opinion, should behave similarly to completion list. On the other hand `minibuffer-completion-help' does not use `display-buffer-overrining-action'. I do not like that this variable has higher priority than `display-buffer-alist'. Action argument of `display-buffer' is more appropriate since it keeps ability to customize placement of buffers with particular names through `display-buffer-alist'.

I don't fully understand the `display-buffer-alist` definition, and copied mostly from the documentation examples.

I hope this helps.

Best regards,
Jan


PS: Sorry for the empty mail I sent previously.


--------------Jhc1SQnp50oAw20oahbBjpUt--