GNU bug report logs - #67249
30.0.50; `same-frame` equivalent for `display-buffer-alist`

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 67249 <at> debbugs.gnu.org
Subject: bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`
Date: Wed, 22 Nov 2023 09:02:03 +0100

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.