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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, shipmints <at> gmail.com
Subject: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis make_frame.c
Date: Thu, 13 Feb 2025 01:39:45 -0800

martin rudalics <rudalics <at> gmx.at> 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?

Previous Next

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