GNU bug report logs - #75828
[PATCH] Correct make-frame docstring vis-a-vis make_frame.c

Previous Next

Full log

Message #14 received at 75828 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75828 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Sat, 25 Jan 2025 10:21:52 -0500

[Message part 1 (text/plain, inline)]

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 <shipmints <at> gmail.com> 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 <eliz <at> gnu.org> wrote:
>
>> > From: Ship Mints <shipmints <at> gmail.com>
>> > 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.
>>
>

[Message part 2 (text/html, inline)]

Previous Next

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