From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Stefan Monnier via "Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
Newsgroups: gmane.emacs.bugs
Subject: bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`
Date: Wed, 22 Nov 2023 11:03:32 -0500
Message-ID: <jwv8r6pssbu.fsf-monnier+emacs@gnu.org>
References: <jwv34x4m50o.fsf@iro.umontreal.ca>
 <159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@gmx.at>
 <jwv1qcmfm22.fsf-monnier+emacs@gnu.org>
 <cbc6a073-2718-7809-c85e-cf338341c712@gmx.at>
 <jwvv89xesho.fsf-monnier+emacs@gnu.org>
 <69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@gmx.at>
 <jwvwmucd0mq.fsf-monnier+emacs@gnu.org>
 <69387717-1eaa-6019-0000-4c95c61e1bc3@gmx.at>
 <jwvwmubrkx7.fsf-monnier+emacs@gnu.org>
 <1f026837-af56-435f-9d4e-048a18af07eb@gmx.at>
Reply-To: Stefan Monnier <monnier@iro.umontreal.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="6481"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cc: 67249@debbugs.gnu.org
To: martin rudalics <rudalics@gmx.at>
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 22 17:04:25 2023
Return-path: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>
Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org
Original-Received: from lists.gnu.org ([209.51.188.17])
	by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>)
	id 1r5piB-0001R6-79
	for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Nov 2023 17:04:23 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <bug-gnu-emacs-bounces@gnu.org>)
	id 1r5phx-0005yr-B2; Wed, 22 Nov 2023 11:04:09 -0500
Original-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 <Debian-debbugs@debbugs.gnu.org>)
 id 1r5phn-0005uY-1d
 for bug-gnu-emacs@gnu.org; Wed, 22 Nov 2023 11:03:59 -0500
Original-Received: from debbugs.gnu.org ([2001:470:142:5::43])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1r5phm-0000ZE-K1
 for bug-gnu-emacs@gnu.org; Wed, 22 Nov 2023 11:03:58 -0500
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
 (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1r5php-00072g-Sj
 for bug-gnu-emacs@gnu.org; Wed, 22 Nov 2023 11:04:01 -0500
X-Loop: help-debbugs@gnu.org
Resent-From: Stefan Monnier <monnier@iro.umontreal.ca>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Wed, 22 Nov 2023 16:04:01 +0000
Resent-Message-ID: <handler.67249.B67249.170066902827045@debbugs.gnu.org>
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 67249
X-GNU-PR-Package: emacs
Original-Received: via spool by 67249-submit@debbugs.gnu.org id=B67249.170066902827045
 (code B ref 67249); Wed, 22 Nov 2023 16:04:01 +0000
Original-Received: (at 67249) by debbugs.gnu.org; 22 Nov 2023 16:03:48 +0000
Original-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@debbugs.gnu.org>)
 id 1r5phc-000729-04
 for submit@debbugs.gnu.org; Wed, 22 Nov 2023 11:03:48 -0500
Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54951)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@iro.umontreal.ca>) id 1r5phZ-00071t-9h
 for 67249@debbugs.gnu.org; Wed, 22 Nov 2023 11:03:46 -0500
Original-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==
Original-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)
Original-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)
In-Reply-To: <1f026837-af56-435f-9d4e-048a18af07eb@gmx.at> (martin rudalics's
 message of "Wed, 22 Nov 2023 09:02:03 +0100")
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
X-BeenThere: bug-gnu-emacs@gnu.org
List-Id: "Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-gnu-emacs>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org
Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.bugs:274762
Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/274762>

>> 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