Subject: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis make_frame.c

From: Stefan Kangas <[email-masked]>
Date: Thu, 13 Feb 2025 01:39:45 -0800

martin rudalics <[email-masked]> writes:

>>> +By default this function does not display the current buffer in the new
>>> +frame if the buffer is hidden, that is, if its name starts with a space.
>>> +However, if the variable @code{expose-hidden-buffer} is either @code{t}
>>> +or equals the symbol @code{make-frame}, it will display the current
>>> +buffer even if it is hidden.
>>
>> This text should IMO say that the function will display another buffer
>> instead of a hidden one.  The wording above could be interpreted as
>> meaning it will display nothing at all.
>>
>>> +By default do not display the current buffer in the new frame if the
>>> +buffer is hidden, that is, if the buffer's name starts with a space.
>>> +However, if `expose-hidden-buffer' is either t or equals the symbol
>>> +`make-frame', display the current buffer even if it is hidden."
>>
>> Same here.
>
> Should have been addressed now.  Please have a look.
>
>> I also wonder why the value t alone is not enough.  It might be
>> confusing to have a symbol whose name is the same as the name of a
>> function, so if we can do with t alone, I'd prefer that.
>
> I left it at non-nil for the moment.  We can use a scalar like
> 'make-frame' or a list like '(make-frame other-frame) if people want it.
>
> martin

I see that dc6b3560e56 was installed.  Does that conclude this bug or is
there more to do here?