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: Thu, 23 Nov 2023 10:59:55 +0100

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

Previous Next

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