From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id UE6GIXJL8GZ+ogAA62LTzQ:P1 (envelope-from ) for ; Sun, 22 Sep 2024 16:53:06 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id UE6GIXJL8GZ+ogAA62LTzQ (envelope-from ) for ; Sun, 22 Sep 2024 18:53:06 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=l2LwVw92; 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=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1727023986; 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=KApzIA+qeiYEPd0YST1TqX8x8iggucp72rVXMp9DSJs=; b=R5JIxsaPGJ8W/TD0wArkWDXNk1yjNjs6TACMPUM1HAWIjbhdls5fbW7O3usxnz4Wlkuws1 kpM8/FymQMkWiXrb2RmH7CRT7ey+d9vlZ5bBUx8O8TyXt0dl0L46eeqALwSt4w8DE5C2lB vC8IEbnxH7v7a5kS++hNPIgIgOJSAofdT7ZBDXOBRPOANJGsyJBxRK/WsQiNsmW1PsiE8t gUPaD8AAhubSrCr4PhWeeAeAJ6IhGDiy1vNuzDtk9Rrn79qfCk7T5Nxc3HnSiYM4TzpNjm ZCxZr8H09zf8DDSX3XWOH3qD+JAdRgE1nrfYinUgCed4Xclj6P1f2jZs+/AdIQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=l2LwVw92; 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=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1727023986; a=rsa-sha256; cv=none; b=KoscGoSllqj275Pt9mEIoLePYNPm/Gv/9ViTWC6PfdaiLwQUI2T7vsFHY1bGYmJECJtPW4 ejgCHIVvpsLeuyRM4gCuX2L2ZaSaklH17HqB2wOG6NR4KQFloGOZ85aPG8X3M2kWpBWDva g/zglu5s73epHPZ7bNhWdE/kakzsHEgu3PZe9vGwLH+60JMdocg4YMCeAuMHH8PY94DZjW iVfVWIwftW7dJec9++s0qxP4+YH8QZgMABbwWFsVdh7XGbVUeBIlbnnRVQ+8DezKc2g+LP q9wfBPiHp2T2ELqnkzC0VwaRg363KeZCtwWovDWjIMo/SpPBQAL8CbCdvI6e3A== 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 4E37F70D40 for ; Sun, 22 Sep 2024 18:53:06 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ssPp9-0007wD-L5; Sun, 22 Sep 2024 12:52:39 -0400 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 1ssPp8-0007w4-Df for emacs-orgmode@gnu.org; Sun, 22 Sep 2024 12:52:38 -0400 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ssPp4-0003wQ-Sv for emacs-orgmode@gnu.org; Sun, 22 Sep 2024 12:52:38 -0400 Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-7191df6b5f5so2226074b3a.0 for ; Sun, 22 Sep 2024 09:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727023952; x=1727628752; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KApzIA+qeiYEPd0YST1TqX8x8iggucp72rVXMp9DSJs=; b=l2LwVw92hDvCyyt7WusrSZG4Z4tFR45jsA/h7rsQ12pd3Tp45QqAofxnID4g3dOWB+ ZqkGgDF2obdpIsTL1o2dLNpcvEMqqZiK0Nyh3yz/oGAudG1IHli7KVIJ3d+PWhwaDJGH Z7D+Z7GjAtA/yxfR39WxX0TpGESSnNM7N8Wut8s0K5D80szki/IImvzYxfWBHHEUA+Ho jHmUjoz6HMaVwFx9xbX4It5kb5CCTCsUef0zxgHJsMud17qZbv9KD2T3KCLBpDM6/JZo 9RD7slA1RAnJKyf1VkcRs3XSO6fGVR5unzUoEvsYximzoUUiX8HZiDtXDZQi8HRBO0/w BLqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727023952; x=1727628752; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KApzIA+qeiYEPd0YST1TqX8x8iggucp72rVXMp9DSJs=; b=g1lSdf2K3zlQKlq5xvhKnIyx2SB3EgLb0KIuzO0U43WD3SzPl6mIadoWe/Z5p6dJGe XV4Fi+IiPYSeYfmNG3kHQYM1lRIOrRQ8v+Ka1qwkv7bUGrY9jCZTgJggGzdSKSy49non BTI6pCEKzrYeSILOMOoQzgHWZ3b7zfBEbazIyFcx1S3QnPXY6+fzzPMpzrPlKnWP5tCL QiLs+yL4w3pAuBaaHiICvrdjXmU77zBjrYnf9gdiAS53Lh7zHdTv4ZVbq516UJ99Wzw8 oI4vfwwBwFJni83/t+0IHRfy85qatZ7WS2aTIOgwybyYZM4GtwteHvYDhAj5T6hHdZzQ 9hCw== X-Gm-Message-State: AOJu0YzyvWxj9PMFx5OPfVE+Iv6NjYqLRBGw1P/dGTlzr9Cs1S3ODbn1 Ms8tRU+V5vyd0EJgpk10dXTj0CNmNk48orcrHB9DwjDW+/pxSpNJmwDFFBMXpdDhICxy5sRvzjM ikT7cMBB1lXsHFHr1zjUgQpAA1Pw= X-Google-Smtp-Source: AGHT+IFKKIEoFrwT/AD8UtvHiR3Xr9a56AwUXFJ6BlSgsrouD+Gfje1L+voeTNDiMKfs5mE+8GbGW8z5YhGL3IQ/vwg= X-Received: by 2002:a05:6a00:3cca:b0:706:58ef:613 with SMTP id d2e1a72fcca58-7199cebda64mr13842824b3a.27.1727023952350; Sun, 22 Sep 2024 09:52:32 -0700 (PDT) MIME-Version: 1.0 References: <87wmjbmmge.fsf@localhost> <87ed5ijeuw.fsf@localhost> <875xqortcj.fsf@localhost> In-Reply-To: <875xqortcj.fsf@localhost> From: Amol Vaidya Date: Sun, 22 Sep 2024 11:52:20 -0500 Message-ID: Subject: Re: Org-Capture Window Behavior To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="00000000000032dc600622b819f2" Received-SPF: pass client-ip=2607:f8b0:4864:20::434; envelope-from=amolvaidya06@gmail.com; helo=mail-pf1-x434.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -5.61 X-Spam-Score: -5.61 X-Migadu-Queue-Id: 4E37F70D40 X-Migadu-Scanner: mx10.migadu.com X-TUID: mmVBiB4VSnC7 --00000000000032dc600622b819f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Again, I apologize for sending this email to you twice Ihor. I keep forgetting to hit reply-all. Anyway... Thank you for your clarification. Just a minor point: my concern is that org-capture is not adhering to general display-buffer settings rather than specifically display-buffer-alist. In my case display-buffer-alist is nil when I run emacs -q, but according to section 29.13.1 of the Elisp manual, if display-buffer-alist is nil, then display-buffer should consult the display-buffer-base-action user option to decide where to display a buffer. In my setup, when I run emacs -q display-buffer-base-action has the following value ((display-buffer--maybe-same-window display-buffer-reuse-window display-buffer--maybe-pop-up-frame-or-window display-buffer-in-previous-window display-buffer-use-some-window display-buffer-pop-up-frame)). So the steps to reproduce the behavior I'm encountering are as follows 1. Run emacs -q 2. C-x 3 C-x 3 to split the frame into three windows. 3. M-x org-capture [RET] t At this point, only two windows are displayed, rather than the three that were originally open. I'm not entirely familiar with what all the display-functions in display-buffer-base-action do, but I don't believe any of them should result in windows being deleted. This suggests that org-capture may not be respecting that setting. I also tried doing the following two alternative sets of steps, both leading to the same behavior TEST 1: 1. Run emacs -q 2. M-x ielm 3. In ielm, run (setq display-buffer-base-action '((display-buffer-same-window))) 4. C-x 3 C-x 3 to split the frame into three windows 5. M-x org-capture [RET] t ---------------------------------------------------------------------------= --------------------------------- TEST 2: 1. Run emacs -q 2. M-x ielm 3. In ielm, run (add-to-list 'display-buffer-alist '("\\*CAPTURE*" (display-buffer-same-window))) 4. C-x 3 C-x 3 to split the frame into three windows 5. M-x org-capture [RET] t In both cases, after running org-capture, all other windows are deleted except one, regardless of the settings in display-buffer-base-action or display-buffer-alist. This leads me to believe that org-capture may not be respecting those settings, particularly if delete-other-windows is being called, as appears to be the case in org-capture-place-template. Please let me know if I can provide any additional details or further clarification. Best regards, Amol Vaidya On Sun, Sep 22, 2024 at 3:20=E2=80=AFAM Ihor Radchenko wrote: > Amol Vaidya writes: > > > (Apologies for replying to this twice Ihor, forgot to reply-all last > time.) > > > > The linked video was from an emacs -q, so I have made no modifications = to > > display-buffer-alist, and my understanding is that emacs -q is equivale= nt > > to an empty init file. If that's not correct, I'm not sure what kind of > > reproducer I need to be providing. > > Yes, you are correct. emacs -q is an equivalent to the empty init file. > And what you get with emacs -q is also expected - the default window > placement. > > There is no bug in what you have shown - Org mode uses its defaults (we > need to have some). > > > I am using Emacs 29.4. I am using org 9.7.11. I don't know what the > > protocol for submitting long code excerpts is to this mailing list, so = I > > apologize if this is not the preferred method, but the output of > > org-submit-bug-report is given below. If there is other information I > > should provide, please let me know. > > I am trying to figure out your report that Org mode does not respect > `display-buffer-alist'. Org mode, since Org 9.7, should respect user > customization in `display-buffer-alist'. > > What I want from you is sufficient information for me to replicate the > problem you are seeing on my computer. Without such information, I > simply cannot diagnose the problem. > > The usual way to produce such information is providing detailed steps, > starting from emacs -Q, that demonstrate the problem. > > In your case, it is probably something like > 1. emacs -Q > 2. Evaluate (setq display-buffer-alist ...) > 3. Run M-x org-capture ... > 4. Observe display-buffer-alist not being respected > > See also https://orgmode.org/manual/Feedback.html > > May you please provide such information for me? > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > --00000000000032dc600622b819f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Again, = I apologize for sending this email to you twice Ihor. I keep forgetting to = hit reply-all. Anyway...

Thank you for your clarification. Ju= st a minor point: my concern is that org-capture is not adhering to general= display-buffer settings rather than specifically display-buffer-alist. In = my case display-buffer-alist is nil when I run emacs -q, but according to s= ection 29.13.1 of the Elisp manual, if display-buffer-alist is nil, then di= splay-buffer should consult the display-buffer-base-action user option to= =C2=A0decide where to display a buffer.=C2=A0

In my setup, = when I run emacs -q display-buffer-base-action has the following value

((display-buffer--maybe-same-window=C2=A0
=C2=A0 display-buffer-reuse-window=C2=A0
=C2=A0 display-buffer--maybe-pop-up-frame-or-win= dow=C2=A0
=C2=A0 display-buffer-i= n-previous-window=C2=A0
=C2=A0 di= splay-buffer-use-some-window=C2=A0
=C2=A0 display-buffer-pop-up-frame)).

So the=C2=A0steps to = reproduce the behavior I'm encountering are as follows
1. Run emacs -q
2. C-x 3 C-x 3 to split the frame into three windows.
=
3. M-x org-capture [RET] t=C2=A0
=

At this point, only two windows are displayed, rather than the three that= were originally open. I'm not entirely familiar with what all the disp= lay-functions in display-buffer-base-action do, but I don't believe any= of=C2=A0them should result in windows being deleted. This suggests that or= g-capture may not be respecting that setting.=C2=A0

I also tr= ied doing the following two alternative sets of steps, both leading to the = same behavior

TEST 1:
1. Run emacs -q
2. M-x ielm
3. In ielm, run (setq display-buffe= r-base-action '((display-buffer-same-window)))=C2=A0
<= font face=3D"monospace">4. C-x 3 C-x 3 to split the frame into three window= s
5. M-x org-capture [RET] t

-----------------------------------------------------------------= -------------------------------------------

TEST 2:
1. Run emacs -q
2. M-x ielm
= 3. In ielm, run (add-to-list 'display-buffer-alist '("\\*CAPTU= RE*" (display-buffer-same-window)))
4. C-x 3 C-x 3 to split the frame into three windows
5. M-x org-capture [RET] t

In both cases, after running=C2=A0org-capture, all other wi= ndows are deleted except one, regardless of the settings in=C2=A0disp= lay-buffer-base-action=C2=A0or=C2=A0display-buffer-alist. This leads me to believe that=C2=A0org-capture=C2=A0may not= be respecting those settings, particularly if=C2=A0delete-other-wind= ows=C2=A0is being called, as appears to be the case in=C2=A0or= g-capture-place-template.

Plea= se let me know if I can provide any additional details or further clarifica= tion.

Best regards,
Amol Vaidya



On Sun, Sep 22, 2024 at 3:20=E2=80=AFAM Ihor Radchen= ko <yantar92@posteo.net> w= rote:
Amol Vaidy= a <amolvaidy= a06@gmail.com> writes:

> (Apologies for replying to this twice Ihor, forgot to reply-all last t= ime.)
>
> The linked video was from an emacs -q, so I have made no modifications= to
> display-buffer-alist, and my understanding is that emacs -q is equival= ent
> to an empty init file. If that's not correct, I'm not sure wha= t kind of
> reproducer I need to be providing.

Yes, you are correct. emacs -q is an equivalent to the empty init file.
And what you get with emacs -q is also expected - the default window placem= ent.

There is no bug in what you have shown - Org mode uses its defaults (we
need to have some).

> I am using Emacs 29.4. I am using org 9.7.11. I don't know what th= e
> protocol for submitting long code excerpts is to this mailing list, so= I
> apologize if this is not the preferred method, but the output of
> org-submit-bug-report is given below. If there is other information I<= br> > should provide, please let me know.

I am trying to figure out your report that Org mode does not respect
`display-buffer-alist'. Org mode, since Org 9.7, should respect user customization in `display-buffer-alist'.

What I want from you is sufficient information for me to replicate the
problem you are seeing on my computer. Without such information, I
simply cannot diagnose the problem.

The usual way to produce such information is providing detailed steps,
starting from emacs -Q, that demonstrate the problem.

In your case, it is probably something like
1. emacs -Q
2. Evaluate (setq display-buffer-alist ...)
3. Run M-x org-capture ...
4. Observe display-buffer-alist not being respected

See also https://orgmode.org/manual/Feedback.html

May you please provide such information for me?

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>
--00000000000032dc600622b819f2--