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" 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: References: <159cd3c2-a0c4-63e2-ebb2-ce0f5f8c343e@gmx.at> <69e6899b-9e93-9a97-a8bc-4ce9a9f0ae4c@gmx.at> <69387717-1eaa-6019-0000-4c95c61e1bc3@gmx.at> <1f026837-af56-435f-9d4e-048a18af07eb@gmx.at> Reply-To: Stefan Monnier 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 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: 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 ) 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 ) 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 ) 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 ) 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 ) 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 Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Nov 2023 16:04:01 +0000 Resent-Message-ID: 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 ) 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 ) 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: >> 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