Received: (at 67249) by debbugs.gnu.org; 23 Nov 2023 10:00:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 23 05:00:14 2023
Received: from localhost ([127.0.0.1]:60657 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r66VK-0002b6-Fx
for submit <at> debbugs.gnu.org; Thu, 23 Nov 2023 05:00:14 -0500
Received: from mout.gmx.net ([212.227.15.18]:40069)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1r66VH-0002Zf-7D
for 67249 <at> debbugs.gnu.org; Thu, 23 Nov 2023 05:00:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417;
t=1700733597; x=1701338397; i=rudalics@HIDDEN;
bh=+MijdxZBFXf1qunke5jMpbWMHWxlk2Ca8rze4Ck9xxs=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=A6uRrvtX1pnZ3foDvv6ea3aSdASN9ldW+dTda26Ilty29c+VbsL8SC3g616XgHqo
GGkKFOCgsE9Kp4EywJeX8sIIHHn4ROm2qO6vHrybMdlzVEPHaWeBdj5VhOOiAMaq/
LeJyqiLxGy1frA5Ub1bqP4PXnbVDew0kA2n8y6RhYK0zz4uaMiy6WuPuFxkBdZZGi
xienJxujtTr0SeeVrtfdIpSIC2Ck7MHhF5bjuBdlL/c+VqXDcmd3TLhvT8MoCQO/M
YPj7z8wifCHci3TgMLzfKOvjTdi6opBkttn/2zRvsdhGGYLjhnYPyYim6Zq7ugiy9
uNZfUYiM5K29t4oLpw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.142]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1N7zFZ-1rRSuM1u8h-014yBv; Thu, 23
Nov 2023 10:59:57 +0100
Message-ID: <a3b664a2-bb53-2f84-edb1-ab4d9d3567bd@HIDDEN>
Date: Thu, 23 Nov 2023 10:59:55 +0100
MIME-Version: 1.0
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
`display-buffer-alist`
Content-Language: en-US
To: Stefan Monnier <monnier@HIDDEN>
References: <jwv34x4m50o.fsf@HIDDEN>
<159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN>
<jwv1qcmfm22.fsf-monnier+emacs@HIDDEN>
<cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN>
<jwvv89xesho.fsf-monnier+emacs@HIDDEN>
<69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@HIDDEN>
<jwvwmucd0mq.fsf-monnier+emacs@HIDDEN>
<69387717-1eaa-6019-0000-4c95c61e1bc3@HIDDEN>
<jwvwmubrkx7.fsf-monnier+emacs@HIDDEN>
<1f026837-af56-435f-9d4e-048a18af07eb@HIDDEN>
<jwv8r6pssbu.fsf-monnier+emacs@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <jwv8r6pssbu.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:+TUzftYpzAYTHZL7hh7qw+pt4BDF6nvRXq1yHB7Eh6k4ghZlQdI
T+Nt9RKwoNY3wYZ1qcqxHtTUMom3JtUoin3OHpprqh9GaSoOncjORsI7JuM1s0O6M6ycSx9
GgGQnqmJ322dshbG5x5w2lLrwSXcovANY6Atl8nsng6ax4+COaiIZ1XGy/rXZylYe+Actve
eizHjEAr9oCioBUOd2Ojg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:nSFy6s0cYJ0=;cqxg7VYpZ4Wv8Af23pK/e4Y5FO4
oNXTcMTyuQc14OF578pyryaeHRocznQYqUJ2Ag1cw2ZqMPrtXVd1l0pdSgoUCmmso2bdnbjkM
bSe16SSI0U0yHex4A2LlYOmd3xITwdquVsmFuAzHlQlRFjFORmy8wgBKB5TsyAghIg1EU9Idt
g7nuW4Rv0nq243HLm1FbY9MgQhwbN4t/CUOEW8m1vWQTNB43Q9KQYJqZe5b4JqRwPSPYTcMO5
lN2rRtbWtZvY+OS6/JpRISwqSACTiCbje/vtF9YuLf4TSzPhjtTvBCIVSO7XfNdOoVQQRlKmp
ffWd+gunTCoViqHtupUiCqoOfhKBe0F7GBjVqpdXScYN8s0oeAeTF9CFZENAnVMGufo/LJDJy
8qUtNrFlitWK/gkTX8dEC2M8yAqY2IbrLP6lzS8vcOd8KRT9ZFe3suubRz5P/P1eEbOnHgAve
FSFbgPpkCfHY5/KiNnuqYhDm6u6mY70WSqDci0V6EwNITIhOoAvtv2ULaALJqMAdBOrB29zN9
Cak+4J7VsE8AXczGCcKCR0NC98dXxmHcZcaBwetjO2FKJypS7CxPbQWT9Xm2kX/gKvCAqSFyQ
fuEVL49eCiQ2ONVTYfDPQ+GLa6Q+BToyyQhHKn6fpo95Vx0FW5fCv30emZKLj6jfSVaoUDWW1
cGNrBIQM7Az3z8sJ7DrRYdAUvyIKwwKi8HPwqrEr83/VrlgzUcbvRQVpEvoLdDiTirRsKDKz5
hx6LGzQgtXxf0avSq2ENZI2G4de4SlGFevRl/pCcNPhUpZt8Z3Gdghob7qu4vT3NczJ3n80VL
V7pR8+LZVSXwRTfqRRjPbqt+EuSJga1O9akIbwgGfylMGotKj47c+YmSiTDKAo37GS9oJ3Mpb
rvZUMI2ZV3txRnB9RHCAMwyWsozVAJ6bOYA9bqxEF6YjVi+SVH2XoJVuL7lkAVTe9V8ks1MYe
hUrOzjHCcg6LFoIR6vgVECUDFgE=
X-Spam-Score: 2.8 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> and the customization types that use them (IIRC either
you or Chong >> invented them). > > The customization type is not used for
them (they are internal > variables, not user-facing nor Customiza [...]
Content analysis details: (2.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.142 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.15.18 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 67249
Cc: 67249 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> and the customization types that use them (IIRC either
you or Chong >> invented them). > > The customization type is not used for
them (they are internal > variables, not user-facing nor Customiza [...]
Content analysis details: (1.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.18 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.142 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 T_SCC_BODY_TEXT_LINE No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
>> and the customization types that use them (IIRC either you or Chong
>> invented them).
>
> The customization type is not used for them (they are internal
> variables, not user-facing nor Customizable).
I meant their use in, for example,
(defcustom display-comint-buffer-action display-buffer--same-window-action
>> If OT1H 'same-frame' is ignored when the selected frame is a
>> minibuffer-only frame (so a new frame gets popped up instead) and OTOH
>> the remaining action functions do use the last non-minibuffer frame in
>> such case, then the behavior of 'display-buffer' is inconsistent in my
>> regard.
>
> Ah, yes, I see.
> IIUC, the "inhibit-new-frame" semantics seems less susceptible to this
> problem then the "same-frame", no?
When I type M-x to invoke a custom function for displaying a buffer, I'd
probably want 'inhibit-new-frame' to do what it advertises regardless of
whether I'm in a stand-alone minibuffer frame or in a normal minibuffer
window. But we could add a separate value for 'inhibit-new-frame' like
'may-use-last-nonminibuffer-frame' to regulate that.
martin
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
Received: (at 67249) by debbugs.gnu.org; 22 Nov 2023 16:03:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 22 11:03:48 2023
Received: from localhost ([127.0.0.1]:59724 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r5phc-000729-04
for submit <at> debbugs.gnu.org; Wed, 22 Nov 2023 11:03:48 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54951)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1r5phZ-00071t-9h
for 67249 <at> debbugs.gnu.org; Wed, 22 Nov 2023 11:03:46 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 46F37100068;
Wed, 22 Nov 2023 11:03:36 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1700669015;
bh=oZZmZM73JCz4fdLDuvSPvyPATyNtnpJxcf5sKWlmg+E=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=YkghYlrkGHArou1ma941vrHtpFlw0uxvZcZDsEBdJe+dnn6Ga49VC0PvuURF05vEo
pLMeGvX8vhtnMx+AZ8pA/8IRBuNcNFkVo2bCtnt2nMyyEfLl5lKLsK+/HKRX+ho8Zs
xihtQn4zprzM+RjkJkwkzM+TtXDUa2zX0jdvbGPZIqaK7+NgsbXXlM1hf5RKoFK3c2
JGdBvTwWER/OIt/9EM0iNZAoEtYr5cEEnIGSNBfZOzsw3VO1rAX3D+B8HD/kkhOUnM
2d/SUZhIss+8mZjvWMduvS4NOfNc2yorDYHqn2ifF3/In+mFaaiSjc9RTFQgVSv/7d
mX1bR7OrCMZ6g==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7C68F100033;
Wed, 22 Nov 2023 11:03:35 -0500 (EST)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6F464120253;
Wed, 22 Nov 2023 11:03:35 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
`display-buffer-alist`
In-Reply-To: <1f026837-af56-435f-9d4e-048a18af07eb@HIDDEN> (martin rudalics's
message of "Wed, 22 Nov 2023 09:02:03 +0100")
Message-ID: <jwv8r6pssbu.fsf-monnier+emacs@HIDDEN>
References: <jwv34x4m50o.fsf@HIDDEN>
<159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN>
<jwv1qcmfm22.fsf-monnier+emacs@HIDDEN>
<cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN>
<jwvv89xesho.fsf-monnier+emacs@HIDDEN>
<69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@HIDDEN>
<jwvwmucd0mq.fsf-monnier+emacs@HIDDEN>
<69387717-1eaa-6019-0000-4c95c61e1bc3@HIDDEN>
<jwvwmubrkx7.fsf-monnier+emacs@HIDDEN>
<1f026837-af56-435f-9d4e-048a18af07eb@HIDDEN>
Date: Wed, 22 Nov 2023 11:03:32 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.098 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 67249
Cc: 67249 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> We could, but we could also define the semantics of `same-frame` to have
>> no effect on frame re-use (it would actually be closer to the current
>> semantics). If so, it'd be best to find another name for it along the
>> lines of "no-new-frame".
> Agreed. 'inhibit-pop-up-frame' or 'inhibit-new-frame' would be more in
> accordance with 'inhibit-same-window' and 'inhibit-switch-frame'.
I like `inhibit-new-frame`, thanks.
>>>>> We could add a 'display-buffer--same-frame-action' variable.
>>>> I don't really know what that suggestion means.
>>>> The `--` suggests it'd be some internal detail of `window.el` whereas
>>>> I thought we're discussing the externally visible API and semantics.
>>> It could do what I meant above - translate 'same-frame' internally.
>> What is "it"? `display-buffer--same-frame-action`?
>> Without knowing where you'd use such a variable, it's hard for me to
>> guess what you mean by that.
> It would be similar to 'display-buffer--same-window-action' and
> 'display-buffer--other-frame-action' and could be used in the same way.
These are just implementation details of `switch-to-buffer-other-frame`,
`display-buffer-other-frame`, `pop-to-buffer-same-window`, ...
So, it would still require the introduction of something like
`display-buffer-same-frame` to make use of it.
> But I'm not familiar with these variables
I guess only Chong is familiar with them, then =F0=9F=99=81
> and the customization types that use them (IIRC either you or Chong
> invented them).
The customization type is not used for them (they are internal
variables, not user-facing nor Customizable).
>> So you think the patch I sent is actually more-or-less acceptable
>> (modulo documentation and finding a better name)?
> Yes.
OK, I'll try and get it into an acceptable shape, then.
> If OT1H 'same-frame' is ignored when the selected frame is a
> minibuffer-only frame (so a new frame gets popped up instead) and OTOH
> the remaining action functions do use the last non-minibuffer frame in
> such case, then the behavior of 'display-buffer' is inconsistent in my
> regard.
Ah, yes, I see.
IIUC, the "inhibit-new-frame" semantics seems less susceptible to this
problem then the "same-frame", no?
Stefan
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
Received: (at 67249) by debbugs.gnu.org; 22 Nov 2023 08:02:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 22 03:02:21 2023
Received: from localhost ([127.0.0.1]:57934 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r5iBh-0002QW-0c
for submit <at> debbugs.gnu.org; Wed, 22 Nov 2023 03:02:21 -0500
Received: from mout.gmx.net ([212.227.17.20]:39489)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1r5iBf-0002QK-DN
for 67249 <at> debbugs.gnu.org; Wed, 22 Nov 2023 03:02:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417;
t=1700640127; x=1701244927; i=rudalics@HIDDEN;
bh=M8t8mH7keH59sWzYkigN6b2Jxc0MSHMVlMWxsgTsuik=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=oU7CrPgw+DvLoVHPK9QO7gF8bAo3A2lidiulL7uA+dQ+hjkCx3YQBwjMv/SuTQjM
G9usLtlGeHMxXUq6UYjukn1M12DbuueamabaFVQp8A+aXzd23A8nbHOGUJX9VWTo2
xcWOMSDg9oevSfFBKmx2+7ULAEqHsFbOzrjhy3t7HGPwuJu+dwfsAaAcLltrsZab8
+liEpgwovzmFZrUP6w4oorV5WV0qzPYOCNpm4lm8YA/FgUKOtpMgZ9b4X+OAp8/k2
gL9/Ud7ncLpGguFMJhDXjVznBscl12zqnqaQXRX4L1fCqH14YJIeumNWBV6fjt0Yf
rsbuqXJ70I9EpWVSZg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.1.100] ([212.95.5.5]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MjS9C-1rltkT0Fcw-00kwnc; Wed, 22
Nov 2023 09:02:07 +0100
Message-ID: <1f026837-af56-435f-9d4e-048a18af07eb@HIDDEN>
Date: Wed, 22 Nov 2023 09:02:03 +0100
MIME-Version: 1.0
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
`display-buffer-alist`
Content-Language: en-US
To: Stefan Monnier <monnier@HIDDEN>
References: <jwv34x4m50o.fsf@HIDDEN>
<159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN>
<jwv1qcmfm22.fsf-monnier+emacs@HIDDEN>
<cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN>
<jwvv89xesho.fsf-monnier+emacs@HIDDEN>
<69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@HIDDEN>
<jwvwmucd0mq.fsf-monnier+emacs@HIDDEN>
<69387717-1eaa-6019-0000-4c95c61e1bc3@HIDDEN>
<jwvwmubrkx7.fsf-monnier+emacs@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <jwvwmubrkx7.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:5Ig8+0QthaWGtuVeefXagClFlBCgy2PJQQy2yavuOputQLH1vAx
//NvB9qlfcs7A1Io6bz85dHNw5KUacWmSb1OyhkQccLSWUsyPDvDH9CgjR1GASDhiyALrPp
41YnUnnpezqaoO+277KgnvGEdCJdXM3nih05oukv4MMu7uSpg6WxQx2HF5lU/8FV8FmjpO9
DCUesR0Q8+EHSGXIiYH1g==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:aXz0le6acb4=;HSPWfiJyML/Xbrtk3uPOFx1+0fI
2hnLMg/t6h1/PaKfgOuKjCMpOhP2YiT7pD5LI1ZFaT6h9Ywf/bISar5dCtnAdJpOLJ57qDFZ+
eXzOa6JxGNONKGHdFZrSDGbbCiYXlUhjyeiX4ZvNa1cL48hpV9RHKWCFabSQML3Ypd7YuGkQL
936rjDtnIY0WipvHqD1wKcrPOprWqjSJPeMeXXd+Ws/shx9HP2ZCjwcOsZa5zCx1reWrZQOGX
bzaJg0eMkp4jb+5c/wH55mGre+IpIR47DPTMjBoFuHXYpVqTBgRnppY+wVbYoJecQ6FqtQgmk
9dGlrv5SDYlnFi34JeHd+gieOB72ZiR/vAzvdN2mv1E1+lVeemYGoymAIGNczt5Pr7BqH068M
XqF4siIXRHYTMLCwkqWURZ9fgsQK+dWG91wr/vYID4fOGqWFAHX4rZi6KyK2UhD/Sc0WxJ6X9
ZnAoR+n4FNlgYJJvCD1VDTWkwOJIlcB3gRfODjIMlIc4zheOMzx4t1Ehrk0YXPlzV63S0oTK8
Xu91fY8waAhy7b7s+/4zQIa87ygnU5na9ejoCGucgLGa1/vwcJBbXMC45TG5sX80xoMT03BoX
vy8n783Ad7QhQ2U0jSoAnkORYL5bw/ucjMWmFwFjZLnC+xKIOdonJZjgYHjd38XDqMCG02hOs
vhyLXcPRi+3WvkRT71P8eJ9FcmI0+AaTtQ2plvj/J7bjWbQEKVDziBTUCwSALqiQ0EGGV53Mm
8ba6B09IBQXh6U73YVXZWQZ2LDihYR8vYxo+j2RZpW2wrTV4uimbP19gt8s1kSp0eDwVQ4l6x
NS3GjMc4luTX6nHI+LIRM0WmxOFwAr9tqoAMz2sDw9EECdw2kaJhWqn/lvN5/HKew3fX4I1oJ
te7k06tan54XnPtzVU8mK/2w4IdDcnVv49abbF5ofGXhNQwQuFt1pmrcFmwS24L9iC5/VhynQ
5yspZQ==
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > We could,
but we could also define the semantics of `same-frame`
to have > no effect on frame re-use (it would actually be closer to the
current
> semantics). If so, it'd be best to find another na [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.5 listed in zen.spamhaus.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.20 listed in list.dnswl.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RCVD_IN_MSPIKE_H4 RBL: Very Good reputation (+4)
[212.227.17.20 listed in wl.mailspike.net]
0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 67249
Cc: 67249 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > We could, but we could also define the semantics of `same-frame`
to have > no effect on frame re-use (it would actually be closer to the current
> semantics). If so, it'd be best to find another na [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.20 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.5 listed in zen.spamhaus.org]
0.0 RCVD_IN_MSPIKE_H4 RBL: Very Good reputation (+4)
[212.227.17.20 listed in wl.mailspike.net]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-0.0 T_SCC_BODY_TEXT_LINE No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> We could, but we could also define the semantics of `same-frame` to have
> no effect on frame re-use (it would actually be closer to the current
> semantics). If so, it'd be best to find another name for it along the
> lines of "no-new-frame".
Agreed. 'inhibit-pop-up-frame' or 'inhibit-new-frame' would be more in
accordance with 'inhibit-same-window' and 'inhibit-switch-frame'.
>>>> We could add a 'display-buffer--same-frame-action' variable.
>>> I don't really know what that suggestion means.
>>> The `--` suggests it'd be some internal detail of `window.el` whereas
>>> I thought we're discussing the externally visible API and semantics.
>> It could do what I meant above - translate 'same-frame' internally.
>
> What is "it"? `display-buffer--same-frame-action`?
> Without knowing where you'd use such a variable, it's hard for me to
> guess what you mean by that.
It would be similar to 'display-buffer--same-window-action' and
'display-buffer--other-frame-action' and could be used in the same way.
But I'm not familiar with these variables and the customization types
that use them (IIRC either you or Chong invented them).
> I suspect it might be sufficient, but it would deserve a better name so
> users don't get the wrong impression that it will affect reuse on
> other frames.
>
> So you think the patch I sent is actually more-or-less acceptable
> (modulo documentation and finding a better name)?
Yes.
>> When the selected frame is a minibuffer-only frame, 'display-buffer'
>> usually tries to think of 'last-nonminibuffer-frame' as the selected
>> frame. So probably 'same-frame' should do the same.
>
> Sounds like this is compatible to my suggestion that it's OK to ignore
> `same-frame` when the selected frame is a minibuffer-only frame.
>
>> But all I can do is to hint at inconsistencies in your proposal.
>
> Not sure what's the inconsistency there.
If OT1H 'same-frame' is ignored when the selected frame is a
minibuffer-only frame (so a new frame gets popped up instead) and OTOH
the remaining action functions do use the last non-minibuffer frame in
such case, then the behavior of 'display-buffer' is inconsistent in my
regard.
martin
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
Received: (at 67249) by debbugs.gnu.org; 21 Nov 2023 19:12:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 21 14:12:19 2023
Received: from localhost ([127.0.0.1]:57435 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r5WAU-0003nr-VC
for submit <at> debbugs.gnu.org; Tue, 21 Nov 2023 14:12:19 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19566)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1r5WAS-0003nc-FH
for 67249 <at> debbugs.gnu.org; Tue, 21 Nov 2023 14:12:17 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BA9751000AD;
Tue, 21 Nov 2023 14:12:07 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1700593926;
bh=aQCpZsYV1wvys4hnHKS3HeQkKPWEExihLnpBMk1ahI4=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=M22aio4ISsO/mgrM//mGhMPW+09BiGBddQBjL3h2tjp4voIPgRLhURMaKoe/elJ4A
19bT+fr+AO1cFjuSrU/Rr1I1dpIVgO7AdbPovvnvsu8gQx+A3bE8uvurug3ONM3OdD
7u9WpV2/SBUYN9dA1nJ+djUYmpQAHQBvfw4ZBT5U+38ocIlRxTudshO7A+gK37zWEy
/gOPu1MB/thMMNXZffok6HcqbKr8MOHaaN3Gkuy+Ojd+RzYnHMBdUfhMD1iWkoIOVR
+z9hUhTYX066dWP8UDsHW+KAi3jiA3RELwXaemYNm8xyiV4QIxwm7+Xs/D6XzXYKFe
28iWG2zuX6pZg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C564A100043;
Tue, 21 Nov 2023 14:12:06 -0500 (EST)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B10011202AA;
Tue, 21 Nov 2023 14:12:06 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
`display-buffer-alist`
In-Reply-To: <69387717-1eaa-6019-0000-4c95c61e1bc3@HIDDEN> (martin rudalics's
message of "Tue, 21 Nov 2023 18:14:38 +0100")
Message-ID: <jwvwmubrkx7.fsf-monnier+emacs@HIDDEN>
References: <jwv34x4m50o.fsf@HIDDEN>
<159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN>
<jwv1qcmfm22.fsf-monnier+emacs@HIDDEN>
<cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN>
<jwvv89xesho.fsf-monnier+emacs@HIDDEN>
<69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@HIDDEN>
<jwvwmucd0mq.fsf-monnier+emacs@HIDDEN>
<69387717-1eaa-6019-0000-4c95c61e1bc3@HIDDEN>
Date: Tue, 21 Nov 2023 14:09:22 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.099 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 67249
Cc: 67249 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> So a (same-frame . t) entry would simply auto-translate to a pair of
>>> (reusable-frames . nil) (lru-frames . nil) entries?
>>
>> [ Hmm... I'm curious how you interpreted what I wrote to reach
>> that conclusion. ]
>> No, I meant the opposite: the users who want to override
>> `reusable-frames` and `lru-frames` need to add all three
>>
>> (same-frame . t)
>> (reusable-frames . nil)
>> (lru-frames . nil)
>
> Suppose an application calls =E2=80=98display-buffer=E2=80=99 with a non-=
nil
> 'same-frame' alist entry. If we want an existing action function to
> obey that entry and we do not want to rewrite that function, we could
> have 'display-buffer' add a (reusable-frames . nil) (lru-frames . nil)
> pair to the alist.
We could, but we could also define the semantics of `same-frame` to have
no effect on frame re-use (it would actually be closer to the current
semantics). If so, it'd be best to find another name for it along the
lines of "no-new-frame".
>>> We could add a 'display-buffer--same-frame-action' variable.
>> I don't really know what that suggestion means.
>> The `--` suggests it'd be some internal detail of `window.el` whereas
>> I thought we're discussing the externally visible API and semantics.
> It could do what I meant above - translate 'same-frame' internally.
What is "it"? `display-buffer--same-frame-action`?
Without knowing where you'd use such a variable, it's hard for me to
guess what you mean by that.
>> I don't see why you think it'd require any change in existing code: the
>> ones who set `same-frame` get what they ask for.
> You already would change the existing 'display-buffer-pop-up-frame'.
> If you think that change is sufficient, I will obviously stop thinking.
I suspect it might be sufficient, but it would deserve a better name so
users don't get the wrong impression that it will affect reuse on
other frames.
So you think the patch I sent is actually more-or-less acceptable
(modulo documentation and finding a better name)?
>> I'm not talking about `display-buffer` choosing a minibuffer-only frame.
>> I'm saying that when the selected-frame is a minibuffer-only frame, it's=
OK
>> to ignore the `same-frame` request.
> When the selected frame is a minibuffer-only frame, 'display-buffer'
> usually tries to think of 'last-nonminibuffer-frame' as the selected
> frame. So probably 'same-frame' should do the same.
Sounds like this is compatible to my suggestion that it's OK to ignore
`same-frame` when the selected frame is a minibuffer-only frame.
> But all I can do is to hint at inconsistencies in your proposal.
Not sure what's the inconsistency there.
Stefan
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
Received: (at 67249) by debbugs.gnu.org; 21 Nov 2023 17:14:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 21 12:14:55 2023
Received: from localhost ([127.0.0.1]:57350 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r5UKt-0000b8-2t
for submit <at> debbugs.gnu.org; Tue, 21 Nov 2023 12:14:55 -0500
Received: from mout.gmx.net ([212.227.17.22]:47425)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1r5UKq-0000aq-Ou
for 67249 <at> debbugs.gnu.org; Tue, 21 Nov 2023 12:14:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417;
t=1700586880; x=1701191680; i=rudalics@HIDDEN;
bh=pOrX8B7WEtgUutiBUIvXWBj2a5v7DIEINCRJsddTMeo=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=GiTjII5mt3KH4wU59LoRFuUFKmOGYcWOlSKXby+ahdfFp5aN3CHHFrNpnNRphHsP
eEWHqczbn/5BkHUayH98SvYphw7BqnASGldoonL5H6guqUJzcHrqMGDvLrQ2/LZcQ
a8xBpxJHw7Qr/yxtfLP2v2aAkDW5earhjCBrs9T1A0EI/fIiHEeOz+mz8UYHk2gCr
h1o7lWHElx8XhSOPj8uRgB5AGWwF6oJc6IG1UBGrAHF6xMXZSGff9cgkeQUS5PX6T
kBkex9DI0nuHggeDhSwC+r5Pu3AWcajTxcs0g7N/DYXONdzqEwmR5CoqL5MsPwIew
u47yGPQDtQIU5MGxiw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.1.100] ([212.95.5.176]) by mail.gmx.net (mrgmx104
[212.227.17.168]) with ESMTPSA (Nemesis) id 1Mgeo8-1rWs0K1d08-00h6Ps; Tue, 21
Nov 2023 18:14:40 +0100
Message-ID: <69387717-1eaa-6019-0000-4c95c61e1bc3@HIDDEN>
Date: Tue, 21 Nov 2023 18:14:38 +0100
MIME-Version: 1.0
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
`display-buffer-alist`
Content-Language: en-US
To: Stefan Monnier <monnier@HIDDEN>
References: <jwv34x4m50o.fsf@HIDDEN>
<159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN>
<jwv1qcmfm22.fsf-monnier+emacs@HIDDEN>
<cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN>
<jwvv89xesho.fsf-monnier+emacs@HIDDEN>
<69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@HIDDEN>
<jwvwmucd0mq.fsf-monnier+emacs@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <jwvwmucd0mq.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
X-Provags-ID: V03:K1:if8pGmiHrEqFJDB9HSUM2TCvMEBwO7evnRHgT8YdWZulXQx2n90
Fla4WKww8E5S5SUaicwIQfkskgtcgFO0AHUPhtgROxPIpthx1UpOKXNiPdc415rw/z9WVS2
2DElT+33sBqmjU6zlaDbMxzF7ncP06wJurdBRd9NpOtOZXjtF7Y6xln9RO6TWPAPWRhMi17
zT5+I/AFWCTXuawQZRlFg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:/Mzth5UMsMg=;ZjcLip1G4fO7sVohGNlXcGVAAbu
Gzg6ifco7CKTga17CWkHUGzleCWbx4qF7gprNqRgYSazyit/dusjuYiEW0VbtHUZR6o53F7QT
tNtzxnm+1qgy6rg7lXzYfl0DFOu5EugKcfhFQK9cN7jta0qSt3lRE1PCoiE+l4Nv1dHbSzI10
8qnC5K7pLZyhFtYFdyGt8N4AZPv+PIf16zHo657lqh+HhJRqwxPHj9QezYL1QMPmDjUoGPJs4
qWEIVHG//Su+Qv8Z9ULDcvpuCc0Rzp1MzXNGS9s0nRxy5IGsFTOItrGMaZ9kVyq2vHR7qJ8ME
l+gPmbrf20esdY3BkEQtQW3Ei/v/l2OGAYLTBwBpIhVOurdDQe/J/iQt6VgUvoXxUyqzRvbSo
JMpBlTrxMdAfuXVElhjcNeHWAszspxYrIUPNXpyE2/7eoHVFF/iSKd1KtcydtYbTcLSxZ8OLK
Mjx1boONIQ6ZLaQwDYjjwtn5t6QSB+g8x6vAnZxFZA+6orvxEiH8m8EhOV1dGQq25SFnIe052
c6H2kgOH3QjkqaLSpD9FV7wt3qyPVgpiJhlasgSZ0TyCHDieESYlDyDcktPGAsLYd30d4+qV8
2LN/sPH8i9rx60JXOtrFm4/pPG9+i8oCsNmULcH3EUbjDOLrxOnu6ldJ+eASaLLKxHtHO+77g
1b/mXYsbqO5e7h5OVE+MAGpNG+Ov57lVWXz80Z4VWD9hcDooZAH1Zd3TA0g/iRhpVyI9nyocu
+1NKOYY4z8rl6hrqoooNMxAnRsQuXTWcQXr/jDZLzEAdx9AixdpRFzTh2DrrhEuu6i3mvSxFX
LqcXUHXvZQw9ttiazfJFaQALqyE0sMypf+BtZcpffCzvzqEroE+kVvXn9Ytez6L5Ak5Z3oiia
UmnGTqv3ZUlEaVfd6UF3+M4tQi+h3B8TRN/p7vFNnOqHZmQYjGVOMYGqVTxkb9Hp+52nDZBcY
59iFPUitmoJ4RVWl6Y3c1cV1wKs=
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > That depends on the rest of the config, AFAIK. > I tried
the patch I sent on some of my config and it did have an effect > (e.g. when
I open `M-x calendar`, depending the `same-frame` I either > ge [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.176 listed in zen.spamhaus.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.22 listed in list.dnswl.org]
0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.17.22 listed in wl.mailspike.net]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 67249
Cc: 67249 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > That depends on the rest of the config, AFAIK. > I tried
the patch I sent on some of my config and it did have an effect > (e.g. when
I open `M-x calendar`, depending the `same-frame` I either > ge [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.22 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.176 listed in zen.spamhaus.org]
0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.17.22 listed in wl.mailspike.net]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-0.0 T_SCC_BODY_TEXT_LINE No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
ID4gVGhhdCBkZXBlbmRzIG9uIHRoZSByZXN0IG9mIHRoZSBjb25maWcsIEFGQUlLLg0KID4g
SSB0cmllZCB0aGUgcGF0Y2ggSSBzZW50IG9uIHNvbWUgb2YgbXkgY29uZmlnIGFuZCBpdCBk
aWQgaGF2ZSBhbiBlZmZlY3QNCiA+IChlLmcuIHdoZW4gSSBvcGVuIGBNLXggY2FsZW5kYXJg
LCBkZXBlbmRpbmcgdGhlIGBzYW1lLWZyYW1lYCBJIGVpdGhlcg0KID4gZ2V0IG9uZSBmcmFt
ZSB3aXRoICpDYWxlbmRhciogYW5kIGFub3RoZXIgd2l0aCBgZGlhcnlgIG9yIEkgZ2V0DQog
PiBhIHNpbmdsZSBmcmFtZSB3aXRoIGJvdGguICBCb3RoIHdpbmRvd3MgYXJlIGRlZGljYXRl
ZCkuDQoNCk5laXRoZXIgb2YgdGhlc2UgZGVhbCB3aXRoICdyZXVzYWJsZS1mcmFtZXMnIG9y
ICdscnUtZnJhbWVzJy4NCg0KID4+IFNvIGEgKHNhbWUtZnJhbWUgLiB0KSBlbnRyeSB3b3Vs
ZCBzaW1wbHkgYXV0by10cmFuc2xhdGUgdG8gYSBwYWlyIG9mDQogPj4gKHJldXNhYmxlLWZy
YW1lcyAuIG5pbCkgKGxydS1mcmFtZXMgLiBuaWwpIGVudHJpZXM/DQogPg0KID4gWyBIbW0u
Li4gSSdtIGN1cmlvdXMgaG93IHlvdSBpbnRlcnByZXRlZCB3aGF0IEkgd3JvdGUgdG8gcmVh
Y2gNCiA+ICAgIHRoYXQgY29uY2x1c2lvbi4gIF0NCiA+IE5vLCBJIG1lYW50IHRoZSBvcHBv
c2l0ZTogdGhlIHVzZXJzIHdobyB3YW50IHRvIG92ZXJyaWRlDQogPiBgcmV1c2FibGUtZnJh
bWVzYCBhbmQgYGxydS1mcmFtZXNgIG5lZWQgdG8gYWRkIGFsbCB0aHJlZQ0KID4NCiA+ICAg
ICAgKHNhbWUtZnJhbWUgLiB0KQ0KID4gICAgICAocmV1c2FibGUtZnJhbWVzIC4gbmlsKQ0K
ID4gICAgICAobHJ1LWZyYW1lcyAuIG5pbCkNCg0KU3VwcG9zZSBhbiBhcHBsaWNhdGlvbiBj
YWxscyDigJhkaXNwbGF5LWJ1ZmZlcuKAmSB3aXRoIGEgbm9uLW5pbA0KJ3NhbWUtZnJhbWUn
IGFsaXN0IGVudHJ5LiAgSWYgd2Ugd2FudCBhbiBleGlzdGluZyBhY3Rpb24gZnVuY3Rpb24g
dG8NCm9iZXkgdGhhdCBlbnRyeSBhbmQgd2UgZG8gbm90IHdhbnQgdG8gcmV3cml0ZSB0aGF0
IGZ1bmN0aW9uLCB3ZSBjb3VsZA0KaGF2ZSAnZGlzcGxheS1idWZmZXInIGFkZCBhIChyZXVz
YWJsZS1mcmFtZXMgLiBuaWwpIChscnUtZnJhbWVzIC4gbmlsKQ0KcGFpciB0byB0aGUgYWxp
c3QuDQoNCiA+PiBXZSBjb3VsZCBhZGQgYSAnZGlzcGxheS1idWZmZXItLXNhbWUtZnJhbWUt
YWN0aW9uJyB2YXJpYWJsZS4NCiA+DQogPiBJIGRvbid0IHJlYWxseSBrbm93IHdoYXQgdGhh
dCBzdWdnZXN0aW9uIG1lYW5zLg0KID4gVGhlIGAtLWAgc3VnZ2VzdHMgaXQnZCBiZSBzb21l
IGludGVybmFsIGRldGFpbCBvZiBgd2luZG93LmVsYCB3aGVyZWFzDQogPiBJIHRob3VnaHQg
d2UncmUgZGlzY3Vzc2luZyB0aGUgZXh0ZXJuYWxseSB2aXNpYmxlIEFQSSBhbmQgc2VtYW50
aWNzLg0KDQpJdCBjb3VsZCBkbyB3aGF0IEkgbWVhbnQgYWJvdmUgLSB0cmFuc2xhdGUgJ3Nh
bWUtZnJhbWUnIGludGVybmFsbHkuDQoNCiA+IEkgZG9uJ3Qgc2VlIHdoeSB5b3UgdGhpbmsg
aXQnZCByZXF1aXJlIGFueSBjaGFuZ2UgaW4gZXhpc3RpbmcgY29kZTogdGhlDQogPiBvbmVz
IHdobyBzZXQgYHNhbWUtZnJhbWVgIGdldCB3aGF0IHRoZXkgYXNrIGZvci4NCg0KWW91IGFs
cmVhZHkgd291bGQgY2hhbmdlIHRoZSBleGlzdGluZyAnZGlzcGxheS1idWZmZXItcG9wLXVw
LWZyYW1lJy4gIElmDQp5b3UgdGhpbmsgdGhhdCBjaGFuZ2UgaXMgc3VmZmljaWVudCwgSSB3
aWxsIG9idmlvdXNseSBzdG9wIHRoaW5raW5nLg0KDQogPiBJJ20gbm90IHRhbGtpbmcgYWJv
dXQgYGRpc3BsYXktYnVmZmVyYCBjaG9vc2luZyBhIG1pbmlidWZmZXItb25seSBmcmFtZS4N
CiA+IEknbSBzYXlpbmcgdGhhdCB3aGVuIHRoZSBzZWxlY3RlZC1mcmFtZSBpcyBhIG1pbmli
dWZmZXItb25seSBmcmFtZSwgaXQncyBPSw0KID4gdG8gaWdub3JlIHRoZSBgc2FtZS1mcmFt
ZWAgcmVxdWVzdC4NCg0KV2hlbiB0aGUgc2VsZWN0ZWQgZnJhbWUgaXMgYSBtaW5pYnVmZmVy
LW9ubHkgZnJhbWUsICdkaXNwbGF5LWJ1ZmZlcicNCnVzdWFsbHkgdHJpZXMgdG8gdGhpbmsg
b2YgJ2xhc3Qtbm9ubWluaWJ1ZmZlci1mcmFtZScgYXMgdGhlIHNlbGVjdGVkDQpmcmFtZS4g
IFNvIHByb2JhYmx5ICdzYW1lLWZyYW1lJyBzaG91bGQgZG8gdGhlIHNhbWUuICBCdXQgYWxs
IEkgY2FuIGRvDQppcyB0byBoaW50IGF0IGluY29uc2lzdGVuY2llcyBpbiB5b3VyIHByb3Bv
c2FsLg0KDQptYXJ0aW4NCg==
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
Received: (at 67249) by debbugs.gnu.org; 20 Nov 2023 13:34:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 20 08:34:01 2023
Received: from localhost ([127.0.0.1]:52806 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r54PZ-0001iD-26
for submit <at> debbugs.gnu.org; Mon, 20 Nov 2023 08:34:01 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25930)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1r54PU-0001ht-Gy
for 67249 <at> debbugs.gnu.org; Mon, 20 Nov 2023 08:33:59 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 80CA6441331;
Mon, 20 Nov 2023 08:33:48 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1700487227;
bh=KO93ErBOJiXsiuhgZDZxPcn/TNCP0LIZTDA28uDK5jw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=FJCWd+0u+cAlm8VBYTEUZPcd7B9U7TK2A7QlqZ8Yi2lIqnZEaALXglhNLPQv+b2oH
jSBTzAiVuFePBeuBNy7rVqvz4RqvRtUnku6D+vCfNEvkn+95/dYVZF71Q4YUl+NREb
qedGQenIEI6hg1INN5oXfwvD9olGwde3pLO5NGh6rmmdHqGiYyUe7l1bYSHCwE9Cwd
Pjt+EhQxYErZrJbr4Q5Nb1s8I/fqBashbmj5qAm5FAvMUS3PaPZISOlMqgxq/rxsZa
XvFySiYnPsQFdH2qv0gOHveOr71/aC1PggWTK2ZcS4AciRLVpB7GjTbh+3/A0C0xKn
/F6vGXxDyoPxw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2FA624412B1;
Mon, 20 Nov 2023 08:33:47 -0500 (EST)
Received: from pastel (unknown [45.72.227.120])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0AE851202E0;
Mon, 20 Nov 2023 08:33:47 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
`display-buffer-alist`
In-Reply-To: <69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@HIDDEN> (martin rudalics's
message of "Mon, 20 Nov 2023 10:15:55 +0100")
Message-ID: <jwvwmucd0mq.fsf-monnier+emacs@HIDDEN>
References: <jwv34x4m50o.fsf@HIDDEN>
<159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN>
<jwv1qcmfm22.fsf-monnier+emacs@HIDDEN>
<cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN>
<jwvv89xesho.fsf-monnier+emacs@HIDDEN>
<69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@HIDDEN>
Date: Mon, 20 Nov 2023 08:33:46 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.029 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 67249
Cc: 67249 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> BTW creating a new frame is always one last resort of 'display-buffer'.
That depends on the rest of the config, AFAIK.
I tried the patch I sent on some of my config and it did have an effect
(e.g. when I open `M-x calendar`, depending the `same-frame` I either
get one frame with *Calendar* and another with `diary` or I get
a single frame with both. Both windows are dedicated).
>> I don't see a big problem here: we could choose `same-frame` to imply
>> that `reusable-frames` is nil, or we could choose to ignore
>> `same-frame`. Since the code that adds `(same-frame . t)` could just as well
>> also add `(reusable-frames)`, the first choice is less flexible
>> than the second (tho it allows overriding a higher-precedence
>> `reusable-frames` setting), so I'd go with the first choice, which also
>> has the advantage of not requiring any code modification :-)
>
> So a (same-frame . t) entry would simply auto-translate to a pair of
> (reusable-frames . nil) (lru-frames . nil) entries?
[ Hmm... I'm curious how you interpreted what I wrote to reach
that conclusion. ]
No, I meant the opposite: the users who want to override
`reusable-frames` and `lru-frames` need to add all three
(same-frame . t)
(reusable-frames . nil)
(lru-frames . nil)
>> Another approach is to provide a new action.
>> This could be a `display-buffer-same-frame` action which tries its best
>> to use the selected frame.
>> I suspect in many cases the actual intention of `same-frame` was to keep
>> the buffer nearby, so I suspect we could also replace `same-frame` with
>> a `display-buffer-nearby` action.
>>
>> The advantage of an action is that we don't need to decide how existing
>> actions interact with it.
>
> We could add a 'display-buffer--same-frame-action' variable.
I don't really know what that suggestion means.
The `--` suggests it'd be some internal detail of `window.el` whereas
I thought we're discussing the externally visible API and semantics.
>>> Again applications that want to pop up a new frame would then have to
>>> provide a (same-frame . nil) entry.
>> That would seem fair game, IMO.
> It means a change in existing code. Till now, applications were on the
> safe side in this regard since they could always blame others for using
> an obsolete feature.
I don't see why you think it'd require any change in existing code: the
ones who set `same-frame` get what they ask for.
>> I suspect the main exception would be minibuffer-only frames, but we
>> could get fancier if we feel like it (like when the selected frame can't
>> accommodate the `window-min-width` and `window-min-height`, or when we
>> set `inhibit-same-window` (or the selected window is dedicated) and the
>> frame's sole window can't be split).
>
> Do you anywhere see 'display-buffer' choose a minibuffer-only frame?
I'm not talking about `display-buffer` choosing a minibuffer-only frame.
I'm saying that when the selected-frame is a minibuffer-only frame, it's OK
to ignore the `same-frame` request.
Stefan
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
Received: (at 67249) by debbugs.gnu.org; 20 Nov 2023 09:16:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 20 04:16:14 2023
Received: from localhost ([127.0.0.1]:52463 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r50O5-0003Pt-PZ
for submit <at> debbugs.gnu.org; Mon, 20 Nov 2023 04:16:14 -0500
Received: from mout.gmx.net ([212.227.17.22]:47949)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1r50O0-0003PS-GR
for 67249 <at> debbugs.gnu.org; Mon, 20 Nov 2023 04:16:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417;
t=1700471757; x=1701076557; i=rudalics@HIDDEN;
bh=i5gnJRg14wKqOZrJHjuRRaEgn/lCK9crFdvFg36iNeo=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=VkOBg/GzbwJpIui84eXcaUHw++RLCh8hLcu7aSDZ9RZ7rAIWbbj6TNZWnZ5E8zp7
ojWpm/ueupufDGKfHu530+d2KQhQ6m3iLZRyss5XpOO5/liXDgmd81JvReDOyjAqP
CNVXv6yMV5TTlrIrjAwlW8c/w42X97jeIXULQoEkSUBnJuI9MNYhuXBj8EjRsmkDk
SqiuvpI2gYqbLiEi9hPG4LBSAIKZ/a2KvaPUkYK9J+sM8my1Bp01hZ7HSuETPCMys
3gM9CYeDJg0Z/2ucnW8vEqLmrptP36aFKAQMSBOczCUVxALC7gP8MVw03UkEVxCgP
Fm7sKJG6C6M76eoj1w==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.1.100] ([212.95.5.38]) by mail.gmx.net (mrgmx104
[212.227.17.168]) with ESMTPSA (Nemesis) id 1Mkpex-1rlBpb3r3v-00mJm2; Mon, 20
Nov 2023 10:15:57 +0100
Message-ID: <69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@HIDDEN>
Date: Mon, 20 Nov 2023 10:15:55 +0100
MIME-Version: 1.0
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
`display-buffer-alist`
Content-Language: en-US
To: Stefan Monnier <monnier@HIDDEN>
References: <jwv34x4m50o.fsf@HIDDEN>
<159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN>
<jwv1qcmfm22.fsf-monnier+emacs@HIDDEN>
<cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN>
<jwvv89xesho.fsf-monnier+emacs@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <jwvv89xesho.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:BZArRhUgYfJoj1Ozbxd6HoM3RAY8XrGgEG8m4QHR1miMS/BreAL
44NQpA44lHHcdBrbBjs7OPKYd4xRTUifqRkH4cigb0lMHGMAEE7TelXzTlxcrghb5f7JvzR
LtyvS2NFTLSlgX5PFYzWjP82jGRcZmOazl1iyrPnzw8E32UkCXVnz2TlJo76XXsbnCJfFJ3
m6IRRA9LBdl8PXXGC1cZg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:Do6nb6dB2V0=;24DH8+Lx5KQkvyzsvPK0BvkKT1x
ON/NXBHBgFA/C+gcwRYwMThtDV6IabMsrxB8M7NZcxNNT9dyMrxpQo+rf8lEPvHjEV/L/jH6e
h7aqGgKbH4J7odG8L/TIcOFiBjZ/0v99AjHdUGQq0nz7Ky3x+tH778tFp0kqcM+jJTPvVyhNJ
XAK73b2XlyZOEHHbOpDCzljyB2h8wEzw/QKzdu/snEE7aa/p1vQ18YSzZg4k+zgfH9jZNvtTM
+2lfjCBO+8/QtvwiNV67xX3yMv3XpbU6MTUZr1j7vtn5h5WgNUbocNsz+UHmMCwhExpTVqxig
rB74q545aUo0w6CBxZUh48H99QPfH4ZUydZXwNiD0u9oLI+8h++J76oEvIr6o7+uFcRTb+AXd
G/JyplprLnfhGO8yuE25maNvSiXtwnZkNEdPuDGJJCIdEFgjMTZQNc3IpNqesEC04GCKn0dvO
A7A59EcHJIAbqVRoOLO0/zgf0nv6qasmjQAPoT7g4lh33jGL4kIP3sfj+6sK+I3Fjja6nLb8W
sz06tsCMXL2NRd7zql//bFI5809unIHfTBzmZtyINfaAEltfCOvjq2DS1xCjX+00y2fB3CJ2K
b5ZUnkOXlS+833//YdvEuEsb4AOlJkW9XEac6ucx3AesBwYYea5Y1ou1ALmrmNwY+cmCgGBmy
kOjn26dPLR+9+K8JS9/Cgo8b+hIjWT8iYIdEHhkWH/ntfuQDd0b9a8JmdH8+c/zOdD9Fh2W7X
Tl/Fuc6PDtveBpgnhPu+RrBB0iw+6ZNM2npLMO1typ3LSNKy/Pr8kiGzvoLbiJOALyiUhLyjF
xG96d1xOppsMqyvNHMiHb/xEYlJHANhxhW+CwyBpybWc6AkhIdraPfagcbOfLC2W5g/Aalz9y
S+Pu/WBHAzj09UHd0Fw+H11Z1IUD01XoC+GjbUN8w45aj80vgHHlbiNZ5LLQtXuH0t62h+YC/
GsgRfA==
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > Right, so it should probably have been called something
like "no new > frame". We should prominently mention that in the manual then.
BTW creating a new frame is always one last resort of 'display-buffer'.
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.38 listed in zen.spamhaus.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.22 listed in list.dnswl.org]
0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.17.22 listed in wl.mailspike.net]
0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 67249
Cc: 67249 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > Right, so it should probably have been called something
like "no new > frame". We should prominently mention that in the manual then.
BTW creating a new frame is always one last resort of 'display-buffer'.
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.22 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.38 listed in zen.spamhaus.org]
0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.17.22 listed in wl.mailspike.net]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-0.0 T_SCC_BODY_TEXT_LINE No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> Right, so it should probably have been called something like "no new
> frame".
We should prominently mention that in the manual then. BTW creating a
new frame is always one last resort of 'display-buffer'.
> I don't see a big problem here: we could choose `same-frame` to imply
> that `reusable-frames` is nil, or we could choose to ignore
> `same-frame`. Since the code that adds `(same-frame . t)` could just as well
> also add `(reusable-frames)`, the first choice is less flexible
> than the second (tho it allows overriding a higher-precedence
> `reusable-frames` setting), so I'd go with the first choice, which also
> has the advantage of not requiring any code modification :-)
So a (same-frame . t) entry would simply auto-translate to a pair of
(reusable-frames . nil) (lru-frames . nil) entries?
> I don't necessarily want a particular behavior. I want to provide
> a similar functionality, within the constraints of what we can define
> and implement sanely.
>
> So no, I don't necessarily want it to prevail over those other entries.
With the conclusion above it would prevail.
>> mean that it should only inhibit popping up a new frame via
>> 'display-buffer-pop-up-frame'.
>
> That was my conclusion when I looked at the code (concretized in
> my PoC patch).
OK.
> Another approach is to provide a new action.
> This could be a `display-buffer-same-frame` action which tries its best
> to use the selected frame.
> I suspect in many cases the actual intention of `same-frame` was to keep
> the buffer nearby, so I suspect we could also replace `same-frame` with
> a `display-buffer-nearby` action.
>
> The advantage of an action is that we don't need to decide how existing
> actions interact with it.
We could add a 'display-buffer--same-frame-action' variable.
>> Again applications that want to pop up a new frame would then have to
>> provide a (same-frame . nil) entry.
>
> That would seem fair game, IMO.
It means a change in existing code. Till now, applications were on the
safe side in this regard since they could always blame others for using
an obsolete feature.
> I suspect the main exception would be minibuffer-only frames, but we
> could get fancier if we feel like it (like when the selected frame can't
> accommodate the `window-min-width` and `window-min-height`, or when we
> set `inhibit-same-window` (or the selected window is dedicated) and the
> frame's sole window can't be split).
Do you anywhere see 'display-buffer' choose a minibuffer-only frame?
I'm aware of the fact that the
(window--frame-usable-p (last-nonminibuffer-frame))
is broken when a minibuffer-only frame is the only frame left but so far
nobody complained ...
martin
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
Received: (at 67249) by debbugs.gnu.org; 19 Nov 2023 14:58:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 19 09:58:04 2023
Received: from localhost ([127.0.0.1]:51899 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r4jFL-0000fC-H6
for submit <at> debbugs.gnu.org; Sun, 19 Nov 2023 09:58:04 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48286)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1r4jFJ-0000eP-37
for 67249 <at> debbugs.gnu.org; Sun, 19 Nov 2023 09:58:02 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id AA281440B62;
Sun, 19 Nov 2023 09:57:53 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1700405872;
bh=FBCIVNDP+5UTPgW0zmXU9oluA1Ky4lr5FFypbC2RRIo=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=A6jfP5nQ8iYHzrO7zc2JFBs+fL2SNwtg1vqlBD1HMXmFOqStxOflNQClLyZzFjg3q
sM3bTh8f0/jv8te/MC+2VVUm34Zy/v0nx8FECnpH4h6Zzwxkw6Qq0ukMc7azvR1Zh7
TBfIUtLrB6w/PVSFuYDzAWeP10Fmuri8dKMc8KRJHv8El339WmqT/76guNiFSC0504
4lU+NTw+0+MUUEnAXDflE3nY1cemiTRw+9DIfdtv6oQrSo+5VtFXZjc9BFDrdT0JLu
eyT0oIPtZExGbDmhmgRTF9yd0MYdTF/jvvOvsTdVyh5lc+0XZulAM9YkxmE1KF4Xgr
1Ch+PopAUC+kQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3AD65440452;
Sun, 19 Nov 2023 09:57:52 -0500 (EST)
Received: from pastel (unknown [45.72.227.120])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0C5B4120352;
Sun, 19 Nov 2023 09:57:52 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
`display-buffer-alist`
In-Reply-To: <cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN> (martin rudalics's
message of "Sun, 19 Nov 2023 11:35:06 +0100")
Message-ID: <jwvv89xesho.fsf-monnier+emacs@HIDDEN>
References: <jwv34x4m50o.fsf@HIDDEN>
<159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN>
<jwv1qcmfm22.fsf-monnier+emacs@HIDDEN>
<cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN>
Date: Sun, 19 Nov 2023 09:57:51 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.028 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 67249
Cc: 67249 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> Are you referring to whether it's OK to (re)use a window on another
>> frame if it shows the buffer already?
> (Re)use any window on another frame.
Right, so it should probably have been called something like "no new
frame".
> The action alist is flat - whichever entry comes first is used even if
> it is not pertinent to the action chosen. If the action chosen is say
> 'display-buffer-in-previous-window', the frames to investigate are
> currently specified by a 'reusable-frames' entry. If no such entry is
> present, we could check for a 'same-frame' entry. But what should
> 'display-buffer' do when both entries are present with 'same-frame'
> coming first?
I don't see a big problem here: we could choose `same-frame` to imply
that `reusable-frames` is nil, or we could choose to ignore
`same-frame`. Since the code that adds `(same-frame . t)` could just as well
also add `(reusable-frames)`, the first choice is less flexible
than the second (tho it allows overriding a higher-precedence
`reusable-frames` setting), so I'd go with the first choice, which also
has the advantage of not requiring any code modification :-)
> And how would 'display-buffer-use-some-window' and
> 'display-buffer-use-least-recent-window' handle the similar case with a
> 'lru-frames' and a 'same-frame' entry both present?
Same reasoning here.
> If you want 'same-frame' to not prevail in these cases, you probably
I don't necessarily want a particular behavior. I want to provide
a similar functionality, within the constraints of what we can define
and implement sanely.
So no, I don't necessarily want it to prevail over those other entries.
> mean that it should only inhibit popping up a new frame via
> 'display-buffer-pop-up-frame'.
That was my conclusion when I looked at the code (concretized in
my PoC patch).
Another approach is to provide a new action.
This could be a `display-buffer-same-frame` action which tries its best
to use the selected frame.
I suspect in many cases the actual intention of `same-frame` was to keep
the buffer nearby, so I suspect we could also replace `same-frame` with
a `display-buffer-nearby` action.
The advantage of an action is that we don't need to decide how existing
actions interact with it.
> Again applications that want to pop up a new frame would then have to
> provide a (same-frame . nil) entry.
That would seem fair game, IMO.
> The proof of this pudding is in clarifying the "if at all possible" and
> explaining any new special behavior in the manual.
I suspect the main exception would be minibuffer-only frames, but we
could get fancier if we feel like it (like when the selected frame can't
accommodate the `window-min-width` and `window-min-height`, or when we
set `inhibit-same-window` (or the selected window is dedicated) and the
frame's sole window can't be split).
Stefan
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.Received: (at 67249) by debbugs.gnu.org; 19 Nov 2023 10:35:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 19 05:35:24 2023 Received: from localhost ([127.0.0.1]:50090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r4f99-00072A-GT for submit <at> debbugs.gnu.org; Sun, 19 Nov 2023 05:35:23 -0500 Received: from mout.gmx.net ([212.227.15.19]:53203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1r4f94-00071s-Mx for 67249 <at> debbugs.gnu.org; Sun, 19 Nov 2023 05:35:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1700390108; x=1700994908; i=rudalics@HIDDEN; bh=KkU5MzY7gNCFy1S9WvhYOEMtoHapzRQQQwgrNbIGw9c=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=GrlEik6hje4R5uOVepE0iHDWlr8L/nWi/kNRVpIzF48or8xcqd8G8f84/ekZe84H qUR70EQsIbOaACg79j+/b7apibeEnU00fwMmgMuQPQgM062o/DqmnjKb+/or4BwtW Z2ZOyvOqnkFkzokz2pwUDvyScMJidC4SxuQLKghc4CMLKdPVOQEjl8yiuKxj+tw7z T/iJ0ESzViVLyi0S6MLyBYDNF1Tu0UNQySpyjF+JaxHzFW92APdTK/xcwo/DA0DNO tSOmtkDdsyUxdbB6MNoxdQp6fxjmHz/QGm8MTsAypSTIM6u3/epkF0v0s5FoteCv2 8eq8Z9qSdcjDYa8fmg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.1.100] ([213.142.96.3]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mnpns-1rgSwA0oaw-00pMqc; Sun, 19 Nov 2023 11:35:08 +0100 Message-ID: <cbc6a073-2718-7809-c85e-cf338341c712@HIDDEN> Date: Sun, 19 Nov 2023 11:35:06 +0100 MIME-Version: 1.0 Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist` Content-Language: en-US To: Stefan Monnier <monnier@HIDDEN> References: <jwv34x4m50o.fsf@HIDDEN> <159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN> <jwv1qcmfm22.fsf-monnier+emacs@HIDDEN> From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <jwv1qcmfm22.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:3dTzlaAyKPh/h89vIRDizigzEdcA34hjARBUhQIAuMol8w39E+B EAuLoTn16sIYILzRU7deBj/VxE6obteRvqYWmN+92B/3Dg/htN/hnKBzLArqL36GAzkgEeA vGoM9lqEWC3XQ/ey/KlFFMKJfMGvyiJK4dYYHRqobWkNQIswHBhYkLpLwNwayMNNTck7L2E DSA3tTqpiE/fgbpvgNnTw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:O6m03IQ8cNk=;llkGDP20IsLSns3l7siIp2i2Anp kcgQxiiv7JwLlAaHSzi94Izo2tontCu67hrdlE3ugQINCXvLpZWnyyAtzn4vAhLgGGQ8PuOxZ Ha8uS4YAxQaXY3hKQqXo/qJnctyMy766k+SUguz7hslKon/+u4BRYKeyzavmmTlBXZBzzxIaa tEIi2H3erkdGo2BBPfbXeDO2S6O05I9/YQOafFmt2Q0M9f9YnmHVRZCTHB4zDSNYTmlYyUCVd mQthduG2ou1vEAmk8phwHrjFDVjh3fUCluBWwRe6JvV4C6sb6TqG14D2AzUwsSTmv8ePa5pC+ e88AZtFLUEZzPiKZX0LGhhccrSLmwGFZQXjAmjwq4bifoZfjwDYHEjP+0bSck0Fr9Tdrr1Pz1 UGvN0kbKr8wmrM9oVvkwM5ZbNw++xgcbCn+CBk6TVp5rcBtHcH4nK/k8x4YFndhEb7TD/zBH/ Nt0KJkrDQ0bSdHQ00K6CarVYnBIHicmVQrTyr9eKztsHoDZjosaMbihFvBILun3BOhUdInlGG zDhPOVPFxdXl/Bu6sX16C/AHaUpKeuqDtX/TWQ6P4qhDYNakb8WNQ9e5fVmocYdTi/eTn5iX9 6HIPaSQa8D15DGN2zPXqvYe5QN66rdRsJgncUppprLAqnukJ7vJ71ROIWDxv8pdo2U4VF8ceC esF8pxiqq1CAPGHmNSwfVeOqrFjtWfXrtsSP4S+N5ZO9mYRTDpJx0g3hMOQm9xyhkjYadFkPZ 2yiy36BGI6w15AIzCKnwzEAsh8D09wlNEBDir+E5Hg4GGpr9BfpS7Pdw1Az8AsZMi5idjgjQO dyFmXeGwFp32s6gpMq6l7kWyyGyOewWIHQtPOknMyaqsSyp0uUhxinvsS++XlPQKk+G16SljM dFkYNvhOKI36lBs7kiKndO0JfcnJ+FBhgPRns9kGYU+D9LhOx3/t71hEWngjJLiDeJzAggtOJ xRU/OA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 67249 Cc: 67249 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) ID4+PiBBcyBgc3BlY2lhbC1kaXNwbGF5LWJ1ZmZlci1uYW1lc2AgYW5kIGZyaWVuZHMgYXJl IG5lYXJpbmcgdGhlIDEwIHllYXJzDQogPj4+IG9mIGJlaW5nIGRlY2xhcmVkIG9ic29sZXRl LCBJIG5vdGljZWQgdGhhdCBJIGNhbid0IGZpbmQgYW55IHJlcGxhY2VtZW50DQogPj4+IGZv ciB0aGUgYHNhbWUtZnJhbWVgIHBhcmFtZXRlciBpbiBgZGlzcGxheS1idWZmZXItYWxpc3Rg Lg0KID4+IElJUkMgJ3NhbWUtZnJhbWUnIGhhZCBubyBjbGVhciBzZW1hbnRpY3MuDQogPg0K ID4gSW4gYHNwZWNpYWwtZGlzcGxheS0qYD8NCg0KQWxsICdzYW1lLWZyYW1lJyBkaWQgd2Fz IHRvIGluaGliaXQgY2FsbGluZyAnc3BlY2lhbC1kaXNwbGF5LWZ1bmN0aW9uJw0KdmlhDQoN CgkgKGxldCogKChwb3AtdXAtZnJhbWVzIG5pbCkgKHBvcC11cC13aW5kb3dzIHQpDQoJCXNw ZWNpYWwtZGlzcGxheS1yZWdleHBzIHNwZWNpYWwtZGlzcGxheS1idWZmZXItbmFtZXMNCgkJ KHdpbmRvdyAoZGlzcGxheS1idWZmZXIgYnVmZmVyKSkpDQoNClRoYXQgbmV2ZXIgcHJlY2x1 ZGVkIHVzaW5nIGEgd2luZG93IG9uIGFub3RoZXIgZnJhbWUsIGNvbnRyYWRpY3RpbmcgdGhl DQp2ZXJ5IG1lYW5pbmcgb2YgInNhbWUgZnJhbWUiIGFuZCB3YXMgYWx3YXlzIGRvY3VtZW50 ZWQgYXMNCg0KICAgIk90aGVyd2lzZSwgaWYgdGhleSBpbmNsdWRlIChzYW1lLWZyYW1lIC4g dCksIHRoZSBidWZmZXIgaXMgZGlzcGxheWVkDQogICAgaW4gYSBuZXcgd2luZG93IGluIHRo ZSBjdXJyZW50bHkgc2VsZWN0ZWQgZnJhbWUuIg0KDQp3aGljaCBmYWlsZWQgdG8gc2F5IHdo YXQgaGFwcGVucyBpZiBubyBuZXcgd2luZG93IGNvdWxkIGJlIGNyZWF0ZWQgb24NCnRoZSBz ZWxlY3RlZCBmcmFtZS4gIFNvIGhpc3RvcmljYWxseSAnc2FtZS1mcmFtZScgd2FzIGFsd2F5 cyB0aWVkIHRvDQonc3BlY2lhbC1kaXNwbGF5LSonIGFuZCBoYWQgbm8gZWZmZWN0IHdoZW4g dGhhdCB3YXMgdW5jdXN0b21pemVkLg0KDQogPiBBcmUgeW91IHJlZmVycmluZyB0byB3aGV0 aGVyIGl0J3MgT0sgdG8gKHJlKXVzZSBhIHdpbmRvdyBvbiBhbm90aGVyDQogPiBmcmFtZSBp ZiBpdCBzaG93cyB0aGUgYnVmZmVyIGFscmVhZHk/DQoNCihSZSl1c2UgYW55IHdpbmRvdyBv biBhbm90aGVyIGZyYW1lLg0KDQogPiBPdGhlciB0aGFuIHRoaXMsIEkgZG9uJ3Qgc2VlIHdo YXQgd2FzIG5vdCBjbGVhciBhYm91dCBpdHMgc2VtYW50aWNzLg0KID4gQW5kIEkgY2FuJ3Qg c2VlIGFueSByZWFzb24gd2h5IHdlIGNvdWxkbid0IGNsYXJpZnkgdGhlIHNlbWFudGljcy4N Cg0KVGhlIGFjdGlvbiBhbGlzdCBpcyBmbGF0IC0gd2hpY2hldmVyIGVudHJ5IGNvbWVzIGZp cnN0IGlzIHVzZWQgZXZlbiBpZg0KaXQgaXMgbm90IHBlcnRpbmVudCB0byB0aGUgYWN0aW9u IGNob3Nlbi4gIElmIHRoZSBhY3Rpb24gY2hvc2VuIGlzIHNheQ0KJ2Rpc3BsYXktYnVmZmVy LWluLXByZXZpb3VzLXdpbmRvdycsIHRoZSBmcmFtZXMgdG8gaW52ZXN0aWdhdGUgYXJlDQpj dXJyZW50bHkgc3BlY2lmaWVkIGJ5IGEgJ3JldXNhYmxlLWZyYW1lcycgZW50cnkuICBJZiBu byBzdWNoIGVudHJ5IGlzDQpwcmVzZW50LCB3ZSBjb3VsZCBjaGVjayBmb3IgYSAnc2FtZS1m cmFtZScgZW50cnkuICBCdXQgd2hhdCBzaG91bGQNCidkaXNwbGF5LWJ1ZmZlcicgZG8gd2hl biBib3RoIGVudHJpZXMgYXJlIHByZXNlbnQgd2l0aCAnc2FtZS1mcmFtZScNCmNvbWluZyBm aXJzdD8gIEFuZCBob3cgd291bGQgJ2Rpc3BsYXktYnVmZmVyLXVzZS1zb21lLXdpbmRvdycg YW5kDQonZGlzcGxheS1idWZmZXItdXNlLWxlYXN0LXJlY2VudC13aW5kb3cnIGhhbmRsZSB0 aGUgc2ltaWxhciBjYXNlIHdpdGggYQ0KJ2xydS1mcmFtZXMnIGFuZCBhICdzYW1lLWZyYW1l JyBlbnRyeSBib3RoIHByZXNlbnQ/DQoNCk5vdyBpZiB5b3Ugd2FudCAnc2FtZS1mcmFtZScg dG8gcHJldmFpbCBpbiBlaXRoZXIgb2YgdGhlc2UgY2FzZXMsIGl0DQp3aWxsIG5vdCBzdWZm aWNlIHRvIHJld3JpdGUgdGhlIGNvcnJlc3BvbmRpbmcgcGllY2VzIG9mIGNvZGUgd2hlcmUN CmFub3RoZXIgZnJhbWUgd291bGQgYmUgY2hvc2VuLiAgQW55IGFwcGxpY2F0aW9uIHRoYXQg cmVhbGx5IG5lZWRzIGENCndpbmRvdyBvbiBhbm90aGVyIGZyYW1lIHdpbGwgdGhlbiBoYXZl IHRvIHByb3ZpZGUgYSAoc2FtZS1mcmFtZSAuIG5pbCkNCmVudHJ5Lg0KDQpJZiB5b3Ugd2Fu dCAnc2FtZS1mcmFtZScgdG8gbm90IHByZXZhaWwgaW4gdGhlc2UgY2FzZXMsIHlvdSBwcm9i YWJseQ0KbWVhbiB0aGF0IGl0IHNob3VsZCBvbmx5IGluaGliaXQgcG9wcGluZyB1cCBhIG5l dyBmcmFtZSB2aWENCidkaXNwbGF5LWJ1ZmZlci1wb3AtdXAtZnJhbWUnLiAgQWdhaW4gYXBw bGljYXRpb25zIHRoYXQgd2FudCB0byBwb3AgdXAgYQ0KbmV3IGZyYW1lIHdvdWxkIHRoZW4g aGF2ZSB0byBwcm92aWRlIGEgKHNhbWUtZnJhbWUgLiBuaWwpIGVudHJ5Lg0KDQogPj4gQXMg Zm9yIGEgbmV3IHdpbmRvdyBvbiB0aGUgc2VsZWN0ZWQgZnJhbWUsIHVzZQ0KID4+ICdkaXNw bGF5LWJ1ZmZlci1wb3AtdXAtd2luZG93Jy4gIEFzIGZvciBhbnkgb3RoZXIgd2luZG93IG9u IHRoZQ0KID4+IHNlbGVjdGVkIGZyYW1lLCB1c2UgZWl0aGVyIOKAmGRpc3BsYXktYnVmZmVy LXVzZS1zb21lLXdpbmRvd+KAmSBvcg0KID4+IOKAmGRpc3BsYXktYnVmZmVyLXVzZS1sZWFz dC1yZWNlbnQtd2luZG934oCZIHdpdGggYSBuaWwgJ2xydS1mcmFtZXMnDQogPj4gYWN0aW9u IGFsaXN0IGVudHJ5Lg0KID4NCiA+IGBzYW1lLWZyYW1lYCB3YXMgbm90IHF1aXRlIGxpa2Ug YW55IG9mIHRob3NlLCBpdCBzYWlkICJrZWVwIHVzaW5nIHRoZQ0KID4gZGVmYXVsdCBzZXQg b2Ygb3B0aW9ucyBpbiB0aGUgc2FtZSBvcmRlciBvZiBwcmVmZXJlbmNlcywgZXhjZXB0IHRo YXQgaWYNCiA+IGF0IGFsbCBwb3NzaWJsZSwgc2tpcCB0aG9zZSBvcHRpb25zIHdoaWNoIGVu ZCB1cCBkaXNwbGF5aW5nIHRoZSBidWZmZXINCiA+IGluIGFub3RoZXIgZnJhbWUiLg0KDQpU aGUgcHJvb2Ygb2YgdGhpcyBwdWRkaW5nIGlzIGluIGNsYXJpZnlpbmcgdGhlICJpZiBhdCBh bGwgcG9zc2libGUiIGFuZA0KZXhwbGFpbmluZyBhbnkgbmV3IHNwZWNpYWwgYmVoYXZpb3Ig aW4gdGhlIG1hbnVhbC4NCg0KbWFydGluDQo=
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
Received: (at 67249) by debbugs.gnu.org; 19 Nov 2023 03:52:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 18 22:52:55 2023
Received: from localhost ([127.0.0.1]:49724 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r4Yrf-0006qB-Iz
for submit <at> debbugs.gnu.org; Sat, 18 Nov 2023 22:52:55 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29084)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1r4Yrd-0006pz-F5
for 67249 <at> debbugs.gnu.org; Sat, 18 Nov 2023 22:52:54 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8C4211000AD;
Sat, 18 Nov 2023 22:52:46 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1700365965;
bh=68pUDhmaILn5ezDcXTZhGI8pn0ErPAYlTLMvg5SVHdI=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=aFMKLoywFCT1fshuC1WtAECA2YY/DwbfdMj+f+7jIDDTWu5+iIslHQQ2XzRq6Esuf
XZqk4l5equdeOXdWigtpp+v6R/ASB596OVweZSbQPbaOalKvQW11i/s0VDYYo7niqq
hMIR7CeKAnbNocIuSYZQzvFizbKT7B305pb6r0n3+pjd9nd6M4M5Nin1YYBFcEJuI7
1p4R0Nlz6eZms1pMNaLXLuEUOE9Dc6w9yD1NhgmDVwLiUveFpncvzgSsZDGkVg8LAK
CVzSXJliQSP25q+PCDW9Wuys+ognxEX5VGmvCtzCKY2NZx6DI+ksSLFXS2wKPMM9Tf
4pRJH4/RdPvTA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D2E93100043;
Sat, 18 Nov 2023 22:52:45 -0500 (EST)
Received: from pastel (unknown [45.72.227.120])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AC15F1204A3;
Sat, 18 Nov 2023 22:52:45 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for
`display-buffer-alist`
In-Reply-To: <159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN> (martin rudalics's
message of "Sat, 18 Nov 2023 09:36:35 +0100")
Message-ID: <jwv1qcmfm22.fsf-monnier+emacs@HIDDEN>
References: <jwv34x4m50o.fsf@HIDDEN>
<159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN>
Date: Sat, 18 Nov 2023 22:52:45 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.129 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 67249
Cc: 67249 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> As `special-display-buffer-names` and friends are nearing the 10 years
>> of being declared obsolete, I noticed that I can't find any replacement
>> for the `same-frame` parameter in `display-buffer-alist`.
> IIRC 'same-frame' had no clear semantics.
In `special-display-*`?
Are you referring to whether it's OK to (re)use a window on another
frame if it shows the buffer already?
Other than this, I don't see what was not clear about its semantics.
And I can't see any reason why we couldn't clarify the semantics.
> As for a new window on the selected frame, use
> 'display-buffer-pop-up-window'. As for any other window on the
> selected frame, use either =E2=80=98display-buffer-use-some-window=E2=80=
=99 or
> =E2=80=98display-buffer-use-least-recent-window=E2=80=99 with a nil 'lru-=
frames'
> action alist entry.
`same-frame` was not quite like any of those, it said "keep using the
default set of options in the same order of preferences, except that if
at all possible, skip those options which end up displaying the buffer
in another frame".
Stefan
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.Received: (at 67249) by debbugs.gnu.org; 18 Nov 2023 08:36:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 18 03:36:50 2023 Received: from localhost ([127.0.0.1]:47756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r4Gor-0006Lx-W9 for submit <at> debbugs.gnu.org; Sat, 18 Nov 2023 03:36:50 -0500 Received: from mout.gmx.net ([212.227.17.22]:53729) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1r4Gop-0006Lf-Bo for 67249 <at> debbugs.gnu.org; Sat, 18 Nov 2023 03:36:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1700296597; x=1700901397; i=rudalics@HIDDEN; bh=bwCd05ErYBa3NrqvlGm/HPW40yBhcF4p0Ltvufr0/po=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=oB0OKuUsi+pguAakVeTcr+eqfIjBkcsENS/yxdNElBqT/gQZHGbeJibJZWcjXQR5 bNSXk0mMWIU0p6vLlTUnzWlwP+clBdiwSgBhkanPHUcDjWd0n05Hy+ad7jzQUDi2d J8DjAMfD3S67/OuqcFewV1D1qTigLaQHhBAA8yowy/W4azdCx7MnkkleN87q9JwC1 HJ9N3sVVNd+QJfX1AcfzxHfHWLCh/GYKofUmqs6qjqAIOhDSF5MiSyz08I+o8Tiiq YV6rFvwqTT2giwrwwzBp0g2mqW+3DCHh7NsPDaBPbcldJuIHUw+jvJ0SjjDwi0Lpi DQAVPhGxLDxxUiSpsA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.1.100] ([46.125.249.56]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M6Daq-1qxf6i3f6O-006c3x; Sat, 18 Nov 2023 09:36:37 +0100 Message-ID: <159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@HIDDEN> Date: Sat, 18 Nov 2023 09:36:35 +0100 MIME-Version: 1.0 Subject: Re: bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist` Content-Language: en-US To: Stefan Monnier <monnier@HIDDEN>, 67249 <at> debbugs.gnu.org References: <jwv34x4m50o.fsf@HIDDEN> From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <jwv34x4m50o.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:xQDBFPS+Nh+tOaktR8HoMovwsBCWJ+qHHbI/izPE68hH85QqR0v j/0csHN5Zic0RhDKt6z7if4Il7vLbgJDDafzg4KI9gTjX2TVOY/APV2vkKIMKJZIg8TCJsv uwfi2n+Gn9CMtoU5xb1Q7+46nO8ht2SnyyvKTdmZB8wevMGUjlnFlBkpd6NoBtj7DiNk2dF Bg4h3+kNKygdkIxnObpjQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:x385WfMNpDg=;h8I/MpYNfS/8125geAn6tKL4E0Y JoChUFalE4sKEqDhPFCbNjSXAtH05IQ75Odd3Dt7cejVqotYhr3/o0HNVXLI+epqcfwgKYc6Y ih3nfP2xL/rG7IpGDbcz9+PAXwB3/FJJY8BEtDFQbDTzAKvyiobVEP0BIDjRilgJ+s6CB4iOJ Es2ohLjovI9CoSBGGupodKW+VvsY3lwAh9BlHvEftvJcDCQJZZv97biLSck7TYlLa1ttQ5iTc 9ZR/ep5gOjizqAYBAu1wsUEtBoTe9q9pHAB+6BACvpyPdL93gWqsoeITy/rsd2C4MmGXxPIu9 pBPe5nBUFv7UR61jAoAf36Zty5Y4SB/IY8Pw2VXyOq2MtgcnPwcjrOeWmhRDimgl9voeaiLWa mtb1hT//oLFWuA1RT3FegAr2codRXEMuPGsKC83AkGhfLZCyd/L6dgFlYtymlDuu919ku2tAk wWEW+anEiBhDHbkWh9I3fWGFsIEcHkTzmmN3pNvM9eia9OBQVjG0yyFp9GTgzCdGmmFDJ46M5 xuYTpwFPYJZL0lvHTtTV6NXlxEN6kYAB2PE0dyOI/SvuYdEQDodi+6jXBxGC7YsNKQldl2Ugs jEdlHRLKCO0PuY65tZUXs8gqsZJNpcZLveYLeHeGKObEsj5R46ILoj4njxAPEpcxwRGRjc2aT rc/pR8fqfXRKIz6kL/uTAjERTvHvQYaFYN5qN3AviY+U8BWWb9O8Zyr2huqV/m+48MgjUliYQ zOWagL9MjMWbr0o5kH1OiPQv6feoVfvIQ1Kpmm3dT2CItyaY1gGJKc4zNby55TKWCZQBEW/TZ d9Fq/Cj8Xx0JTD4wHcmiuHddm/U1zbc6xLlHvQW0T6g42yYPIYsF5EWsggo+cF+C9OB+GuEz0 NDlA3LRruhyALQTFcEblpKRHw42txhU62eiPldvETdPX8i7Iv4UDMucIay2GNbKFdMkYzHCqx U2t0XEUjOhBTNYDMQWGG9qHwqMM= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 67249 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) ID4gQXMgYHNwZWNpYWwtZGlzcGxheS1idWZmZXItbmFtZXNgIGFuZCBmcmllbmRzIGFyZSBu ZWFyaW5nIHRoZSAxMCB5ZWFycw0KID4gb2YgYmVpbmcgZGVjbGFyZWQgb2Jzb2xldGUsIEkg bm90aWNlZCB0aGF0IEkgY2FuJ3QgZmluZCBhbnkgcmVwbGFjZW1lbnQNCiA+IGZvciB0aGUg YHNhbWUtZnJhbWVgIHBhcmFtZXRlciBpbiBgZGlzcGxheS1idWZmZXItYWxpc3RgLg0KDQpJ SVJDICdzYW1lLWZyYW1lcycgaGFkIG5vIGNsZWFyIHNlbWFudGljcy4gIEFzIGZvciB0aGUg c2VsZWN0ZWQgd2luZG93LA0KdXNlICdkaXNwbGF5LWJ1ZmZlci1zYW1lLXdpbmRvdycuICBB cyBmb3IgYSBuZXcgd2luZG93IG9uIHRoZSBzZWxlY3RlZA0KZnJhbWUsIHVzZSAnZGlzcGxh eS1idWZmZXItcG9wLXVwLXdpbmRvdycuICBBcyBmb3IgYW55IG90aGVyIHdpbmRvdyBvbg0K dGhlIHNlbGVjdGVkIGZyYW1lLCB1c2UgZWl0aGVyIOKAmGRpc3BsYXktYnVmZmVyLXVzZS1z b21lLXdpbmRvd+KAmSBvcg0K4oCYZGlzcGxheS1idWZmZXItdXNlLWxlYXN0LXJlY2VudC13 aW5kb3figJkgd2l0aCBhIG5pbCAnbHJ1LWZyYW1lcycgYWN0aW9uDQphbGlzdCBlbnRyeS4N Cg0KbWFydGluDQo=
bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 17 Nov 2023 21:42:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 17 16:42:06 2023
Received: from localhost ([127.0.0.1]:47261 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r46bG-00063P-3w
for submit <at> debbugs.gnu.org; Fri, 17 Nov 2023 16:42:06 -0500
Received: from lists.gnu.org ([2001:470:142::17]:32948)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1r46bD-00062u-Qn
for submit <at> debbugs.gnu.org; Fri, 17 Nov 2023 16:42:04 -0500
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 <monnier@HIDDEN>)
id 1r46b7-0003HB-Nq
for bug-gnu-emacs@HIDDEN; Fri, 17 Nov 2023 16:41:57 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <monnier@HIDDEN>)
id 1r46b6-0007yy-0d
for bug-gnu-emacs@HIDDEN; Fri, 17 Nov 2023 16:41:57 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1B1CC444325
for <bug-gnu-emacs@HIDDEN>; Fri, 17 Nov 2023 16:41:54 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1700257308;
bh=kHmFV6tXEIsd5EyJsl2evU0nnfSd/L+M5cPaGVaVNUw=;
h=From:To:Subject:Date:From;
b=gRlXrg+8H2vEIpBMwnd8wJHXzxtwqWoooSQ5kULp6Acb+ThzXchoqdvKORLvPSk4h
6R00ojcvLuRRHto6yry0VTWirkfS1V5rtBhfMOhH1g7Zwx9shTOft1Vyeh+LVSnUmf
XTYnVHpHdNs79eJbrKzUhTKZJ5iAi+XvSvUqnHo5YZGOuDuletuZYwVmTb57cALv4q
lNe8h9xR+WqrslfyV6VUms5DsHY2ysvEL1o3M0MtIJT8sJQO24+YYDH3djhyWI7Dm0
+qvaIY5qHgdEj4wDF+ILJjU93bzDaAtHeat7zlsQSFWv9zgW3OsxfeU8rupyA1w8g6
yRo6KvZCuK30A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B323B444323
for <bug-gnu-emacs@HIDDEN>; Fri, 17 Nov 2023 16:41:48 -0500 (EST)
Received: from pastel (unknown [45.72.227.120])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9692912017B
for <bug-gnu-emacs@HIDDEN>; Fri, 17 Nov 2023 16:41:48 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 30.0.50; `same-frame` equivalent for `display-buffer-alist`
X-Debbugs-Cc: Martin Rudalics <rudalics@HIDDEN>, monnier@HIDDEN
Date: Fri, 17 Nov 2023 16:41:43 -0500
Message-ID: <jwv34x4m50o.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.027 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
Received-SPF: pass client-ip=132.204.25.50;
envelope-from=monnier@HIDDEN; helo=mailscanner.iro.umontreal.ca
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Package: Emacs
Version: 30.0.50
As `special-display-buffer-names` and friends are nearing the 10 years
of being declared obsolete, I noticed that I can't find any replacement
for the `same-frame` parameter in `display-buffer-alist`.
The patch below is just a "proof-of-concept" I tried to see if I could
get a similar behavior to the old `same-frame` with the new code.
I'm not sufficiently familiar with the set of `display-buffer-*`
functions to judge if it's a good approach overall.
I also noticed that `special-display-popup-frame` is only called from
`special-display-function` (which is declared obsolete since 24.3), so
maybe it should also be declared obsolete?
Stefan
diff --git a/lisp/window.el b/lisp/window.el
index b6fe5996123..72cd9f5d85c 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -6795,6 +6795,7 @@ special-display-popup-frame
If ARGS is a list whose car is a symbol, use (car ARGS) as a
function to do the work. Pass it BUFFER as first argument, and
pass the elements of (cdr ARGS) as the remaining arguments."
+ (declare (obsolete "??" "30.1"))
(if (and args (symbolp (car args)))
(apply (car args) buffer (cdr args))
(let ((window (get-buffer-window buffer 0)))
@@ -8014,6 +8015,7 @@ display-buffer-pop-up-frame
(fun pop-up-frame-function)
frame window)
(when (and fun
+ (not (alist-get 'same-frame alist))
;; Make BUFFER current so `make-frame' will use it as the
;; new frame's buffer (Bug#15133).
(with-current-buffer buffer
Stefan Monnier <monnier@HIDDEN>:rudalics@HIDDEN, monnier@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.rudalics@HIDDEN, monnier@HIDDEN, bug-gnu-emacs@HIDDEN:bug#67249; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.