I tried. It looks like having a control of some kind for make-frame, or altering make_frame to not use other_buffer_safely, are the only options. make_frame calls other_buffer_safely which ignores the suggested frame parameters. From buffer.c: /* The following function is a safe variant of Fother_buffer: It doesn't pay attention to any frame-local buffer lists, doesn't care about visibility of buffers, and doesn't evaluate any frame predicates. */ Lisp_Object other_buffer_safely (Lisp_Object buffer) On Sat, Jan 25, 2025 at 9:56 AM Ship Mints wrote: > Sure, I'll use buffer-list / buffer-predicate and beat my make-frame > calls into submission. > > In the end, this was a surprise and it took a while to figure out why > make-frame wasn't doing what I asked. I had to read the code for make_frame > to figure this out. That, alone, is a good reason to at least mention it in > the docstring, and will save some other people time. > > > On Sat, Jan 25, 2025 at 9:47 AM Eli Zaretskii wrote: > >> > From: Ship Mints >> > Date: Sat, 25 Jan 2025 09:12:50 -0500 >> > >> > make-frame's docstring says "creates and returns a new frame, >> displaying the current buffer." This is not >> > true if the buffer is considered conventionally hidden. >> > >> > struct frame * >> > make_frame (bool mini_p) >> > ... >> > Lisp_Object buf = Fcurrent_buffer (); >> > /* If current buffer is hidden, try to find another one. */ >> > if (BUFFER_HIDDEN_P (XBUFFER (buf))) >> > buf = other_buffer_safely (buf); >> > >> > I'd prefer to have an option to be literal and allow users to make a >> frame on a hidden current buffer. >> >> You can have that already via buffer-list and/or buffer-predicate frame >> parameters, no? >> >> > --- a/lisp/frame.el >> > +++ b/lisp/frame.el >> > @@ -915,6 +915,10 @@ x-display-name >> > >> > (defun make-frame (&optional parameters) >> > "Return a newly created frame displaying the current buffer. >> > +If the current buffer is hidden (its name starts with a space >> > +character), then another buffer is chosen to display following the >> > +semantics of `other-buffer'. >> >> Thanks, but this is inaccurate: it is incorrect, for example, if >> PARAMETERS include '((minibuffer . only)). >> >> I'm not sure we should reveal those details here. Hidden buffers are >> handled specially in many places in Emacs, and I don't think we spell >> that out in every doc string. >> >> Stefan, WDYT? >> >> In any case, if we do decide to make this change, the ELisp manual >> should also be changed. >> >