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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75828 in the body.
You can then email your comments to 75828 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Ship Mints <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Correct make-frame docstring vis-a-vis make_frame.c
Date: Sat, 25 Jan 2025 09:12:50 -0500

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

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. I might submit this idea under a different bug
for discussion.

-Stephane

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

[0001-make-frame-docstring-matches-frame.c-if-current-buff.patch (application/octet-stream, attachment)]

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

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

> 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 #11 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 09:56:40 -0500

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

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

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75828 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Sat, 25 Jan 2025 17:32:30 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Sat, 25 Jan 2025 10:21:52 -0500
> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 75828 <at> debbugs.gnu.org
> 
> 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.

Can you tell why you must use make-frame and not, say,
switch-to-buffer-other-frame?

Message #20 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, 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:47:27 -0500

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

Because I want a guaranteed new frame with the explicitly specified buffer.

I assume this is also an issue for child frames--make_frame doesn't
distinguish during buffer selection?

The following works but is wonky (kind of annoying) because it first shows
a non-hidden buffer, and then switches to the one I really want (note that
string pixel width is just an example that we all have at hand):

(with-selected-frame (make-frame)
  ;; (select-frame-set-input-focus (selected-frame)) ; might need based on
platform
  (switch-to-buffer " *string-pixel-width*"))

-Stephane

On Sat, Jan 25, 2025 at 10:32 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Sat, 25 Jan 2025 10:21:52 -0500
> > Cc: Stefan Kangas <stefankangas <at> gmail.com>, 75828 <at> debbugs.gnu.org
> >
> > 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.
>
> Can you tell why you must use make-frame and not, say,
> switch-to-buffer-other-frame?
>

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75828 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Sat, 25 Jan 2025 18:26:49 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Sat, 25 Jan 2025 10:47:27 -0500
> Cc: stefankangas <at> gmail.com, 75828 <at> debbugs.gnu.org
> 
> Because I want a guaranteed new frame with the explicitly specified buffer.

And pop-to-buffer cannot guarantee that?

Message #26 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, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Sat, 25 Jan 2025 11:31:31 -0500

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

I appreciate the tips and discussion.

(let ((pop-up-frames t))
  (pop-to-buffer " *string-pixel-width*"))

is identical to the wonky snippet, first showing the unwanted buffer then
switching to the wanted buffer (and first paying the display cost for the
original buffer).



On Sat, Jan 25, 2025 at 11:26 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Sat, 25 Jan 2025 10:47:27 -0500
> > Cc: stefankangas <at> gmail.com, 75828 <at> debbugs.gnu.org
> >
> > Because I want a guaranteed new frame with the explicitly specified
> buffer.
>
> And pop-to-buffer cannot guarantee that?
>

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>,
 martin rudalics <rudalics <at> gmx.at>
Cc: 75828 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Sat, 25 Jan 2025 18:43:08 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Sat, 25 Jan 2025 11:31:31 -0500
> Cc: stefankangas <at> gmail.com, 75828 <at> debbugs.gnu.org
> 
> I appreciate the tips and discussion.
> 
> (let ((pop-up-frames t))
>   (pop-to-buffer " *string-pixel-width*"))
> 
> is identical to the wonky snippet, first showing the unwanted buffer then switching to the wanted buffer (and
> first paying the display cost for the original buffer).

That still doesn't justify a new function, IMO.  But maybe Martin will
have even better suggestions.

Message #32 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: martin rudalics <rudalics <at> gmx.at>, stefankangas <at> gmail.com,
 75828 <at> debbugs.gnu.org
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Sat, 25 Jan 2025 11:43:07 -0500

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

Not a new function, just a way to influence make_frame to not test the
current buffer being hidden.

On Sat, Jan 25, 2025 at 11:43 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Sat, 25 Jan 2025 11:31:31 -0500
> > Cc: stefankangas <at> gmail.com, 75828 <at> debbugs.gnu.org
> >
> > I appreciate the tips and discussion.
> >
> > (let ((pop-up-frames t))
> >   (pop-to-buffer " *string-pixel-width*"))
> >
> > is identical to the wonky snippet, first showing the unwanted buffer
> then switching to the wanted buffer (and
> > first paying the display cost for the original buffer).
>
> That still doesn't justify a new function, IMO.  But maybe Martin will
> have even better suggestions.
>

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

Message #35 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: martin rudalics <rudalics <at> gmx.at>, stefankangas <at> gmail.com,
 75828 <at> debbugs.gnu.org
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Sat, 25 Jan 2025 11:54:08 -0500

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

I'd be happy with a new defvar (not even a defcustom) and I'll bind it all
the time (except in packages where I'll bind it around make-frame calls).

On Sat, Jan 25, 2025 at 11:43 AM Ship Mints <shipmints <at> gmail.com> wrote:

> Not a new function, just a way to influence make_frame to not test the
> current buffer being hidden.
>
> On Sat, Jan 25, 2025 at 11:43 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Ship Mints <shipmints <at> gmail.com>
>> > Date: Sat, 25 Jan 2025 11:31:31 -0500
>> > Cc: stefankangas <at> gmail.com, 75828 <at> debbugs.gnu.org
>> >
>> > I appreciate the tips and discussion.
>> >
>> > (let ((pop-up-frames t))
>> >   (pop-to-buffer " *string-pixel-width*"))
>> >
>> > is identical to the wonky snippet, first showing the unwanted buffer
>> then switching to the wanted buffer (and
>> > first paying the display cost for the original buffer).
>>
>> That still doesn't justify a new function, IMO.  But maybe Martin will
>> have even better suggestions.
>>
>

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Ship Mints <shipmints <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 75828 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Sat, 25 Jan 2025 20:17:44 +0100

> I'd be happy with a new defvar (not even a defcustom) and I'll bind it all
> the time (except in packages where I'll bind it around make-frame calls).

I think a new automatically buffer-local variable, say
'display-via-make-frame', would not harm anyone.

martin

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

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

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

If we use a buffer local, I'll have to remove it after make-frame is
complete. If a let-bound variable, users would not have to remember to do
this. Either way, make_frame needs to ignore the specified buffer that
happens to be hidden.

On Sat, Jan 25, 2025 at 2:17 PM martin rudalics <rudalics <at> gmx.at> wrote:

>  > I'd be happy with a new defvar (not even a defcustom) and I'll bind it
> all
>  > the time (except in packages where I'll bind it around make-frame
> calls).
>
> I think a new automatically buffer-local variable, say
> 'display-via-make-frame', would not harm anyone.
>
> martin
>

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Sun, 26 Jan 2025 09:52:45 +0100

> If we use a buffer local, I'll have to remove it after make-frame is
> complete. If a let-bound variable, users would not have to remember to do
> this. Either way, make_frame needs to ignore the specified buffer that
> happens to be hidden.

But a variable is not by design "let-bound".  When this variable is
automatically buffer-local a user can choose

- whether a specific hidden buffer may be shown or not by setting the
  buffer-local value

- whether any hidden buffer may be shown or not by setting the default
  value

- whether only a specific 'make-frame' call is affected by using a
  let-binding.

martin

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

From: Ship Mints <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Mon, 27 Jan 2025 11:54:24 -0500

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

Hi, Martin,

These are the two options on the table?

(let ((frame-inhibit-make-frame-hidden-buffer-check t))
  (with-current-buffer " *string-pixel-width*"
    (make-frame)))
;; could also do this if users want the behavior all the time
(setq frame-inhibit-make-frame-hidden-buffer-check t)

(with-current-buffer " *string-pixel-width*"
  (setq-local frame-inhibit-make-frame-hidden-buffer-check t)
  (make-frame)
  (kill-local-variable 'frame-inhibit-make-frame-hidden-buffer-check))

I prefer the former over the latter. It seems harmonious with other
frame-related controls such as frame-resize-pixelwise
and frame-inhibit-implied-resize, unless I'm missing some subtlety, which I
surely am.

-Stephane

On Sun, Jan 26, 2025 at 3:53 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > If we use a buffer local, I'll have to remove it after make-frame is
>  > complete. If a let-bound variable, users would not have to remember to
> do
>  > this. Either way, make_frame needs to ignore the specified buffer that
>  > happens to be hidden.
>
> But a variable is not by design "let-bound".  When this variable is
> automatically buffer-local a user can choose
>
> - whether a specific hidden buffer may be shown or not by setting the
>    buffer-local value
>
> - whether any hidden buffer may be shown or not by setting the default
>    value
>
> - whether only a specific 'make-frame' call is affected by using a
>    let-binding.
>
> martin
>

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Mon, 27 Jan 2025 19:00:55 +0100

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

> These are the two options on the table?
>
> (let ((frame-inhibit-make-frame-hidden-buffer-check t))
>    (with-current-buffer " *string-pixel-width*"
>      (make-frame)))
> ;; could also do this if users want the behavior all the time
> (setq frame-inhibit-make-frame-hidden-buffer-check t)
>
> (with-current-buffer " *string-pixel-width*"
>    (setq-local frame-inhibit-make-frame-hidden-buffer-check t)
>    (make-frame)
>    (kill-local-variable 'frame-inhibit-make-frame-hidden-buffer-check))
>
> I prefer the former over the latter.

I prefer these ones

(let ((frame-inhibit-make-frame-hidden-buffer-check t))
  (with-current-buffer " *string-pixel-width*"
    (make-frame)))

;; Set the default for all buffers.
(setq-default frame-inhibit-make-frame-hidden-buffer-check t)

;; Set the buffer-local value.
(with-current-buffer " *string-pixel-width*"
  (setq frame-inhibit-make-frame-hidden-buffer-check t))

with the attached patch.

> It seems harmonious with other
> frame-related controls such as frame-resize-pixelwise
> and frame-inhibit-implied-resize, unless I'm missing some subtlety, which I
> surely am.

The subtlety is that a leading space in a buffer name is a buffer-local
property, a property which affects only the buffer wearing that name and
no other buffers.

'frame-resize-pixelwise' and 'frame-inhibit-implied-resize' are (or
better should be) frame properties, properties that affect a frame and
consequently all buffers displayed on that frame.

martin

[frame.c.diff (text/x-patch, attachment)]

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

From: Ship Mints <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Mon, 27 Jan 2025 13:16:13 -0500

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

That works for me applied to a recent master. Happy to use the buffer
local. It's unlikely to cause trouble if a user doesn't kill it, and we'll
understand why if they don't.

On Mon, Jan 27, 2025 at 1:01 PM martin rudalics <rudalics <at> gmx.at> wrote:

>  > These are the two options on the table?
>  >
>  > (let ((frame-inhibit-make-frame-hidden-buffer-check t))
>  >    (with-current-buffer " *string-pixel-width*"
>  >      (make-frame)))
>  > ;; could also do this if users want the behavior all the time
>  > (setq frame-inhibit-make-frame-hidden-buffer-check t)
>  >
>  > (with-current-buffer " *string-pixel-width*"
>  >    (setq-local frame-inhibit-make-frame-hidden-buffer-check t)
>  >    (make-frame)
>  >    (kill-local-variable 'frame-inhibit-make-frame-hidden-buffer-check))
>  >
>  > I prefer the former over the latter.
>
> I prefer these ones
>
> (let ((frame-inhibit-make-frame-hidden-buffer-check t))
>    (with-current-buffer " *string-pixel-width*"
>      (make-frame)))
>
> ;; Set the default for all buffers.
> (setq-default frame-inhibit-make-frame-hidden-buffer-check t)
>
> ;; Set the buffer-local value.
> (with-current-buffer " *string-pixel-width*"
>    (setq frame-inhibit-make-frame-hidden-buffer-check t))
>
> with the attached patch.
>
>  > It seems harmonious with other
>  > frame-related controls such as frame-resize-pixelwise
>  > and frame-inhibit-implied-resize, unless I'm missing some subtlety,
> which I
>  > surely am.
>
> The subtlety is that a leading space in a buffer name is a buffer-local
> property, a property which affects only the buffer wearing that name and
> no other buffers.
>
> 'frame-resize-pixelwise' and 'frame-inhibit-implied-resize' are (or
> better should be) frame properties, properties that affect a frame and
> consequently all buffers displayed on that frame.
>
> martin

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

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Ship Mints <shipmints <at> gmail.com>
Cc: 75828 <at> debbugs.gnu.org
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Mon, 27 Jan 2025 12:30:45 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

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

On first approximation, I'd tend to agree with you, but I think Martin
made a good point later in this discussion, when he said the following.

martin rudalics <rudalics <at> gmx.at> writes:

> I think a new automatically buffer-local variable, say
> 'display-via-make-frame', would not harm anyone.

So I think we could install Martin's proposed patch, with NEWS and doc
changes of course.

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

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

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

Martin, would you prefer to prepare the patch with NEWS and docstring
changes or would you like me to do it?

On Mon, Jan 27, 2025 at 1:30 PM Stefan Kangas <stefankangas <at> gmail.com>
wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > 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?
>
> On first approximation, I'd tend to agree with you, but I think Martin
> made a good point later in this discussion, when he said the following.
>
> martin rudalics <rudalics <at> gmx.at> writes:
>
> > I think a new automatically buffer-local variable, say
> > 'display-via-make-frame', would not harm anyone.
>
> So I think we could install Martin's proposed patch, with NEWS and doc
> changes of course.
>

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 75828 <at> debbugs.gnu.org, shipmints <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Mon, 27 Jan 2025 21:22:16 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 27 Jan 2025 12:30:45 -0600
> Cc: 75828 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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?
> 
> On first approximation, I'd tend to agree with you, but I think Martin
> made a good point later in this discussion, when he said the following.
> 
> martin rudalics <rudalics <at> gmx.at> writes:
> 
> > I think a new automatically buffer-local variable, say
> > 'display-via-make-frame', would not harm anyone.
> 
> So I think we could install Martin's proposed patch, with NEWS and doc
> changes of course.

Fine by me, thanks.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Tue, 28 Jan 2025 10:28:28 +0100

> That works for me applied to a recent master. Happy to use the buffer
> local.

We'd need a shorter name, maybe something like 'make-frame-may-show-it'.

> It's unlikely to cause trouble if a user doesn't kill it, and we'll
> understand why if they don't.

Users who setq it locally or setq-default it know what they want.  Users
who prefer let-binding it won't even notice that it's an automatically
buffer-local variable.

martin

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

From: Ship Mints <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Tue, 28 Jan 2025 04:40:21 -0500

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

Hmm. make-frame-may-show-it doesn't really capture the nature of
make-frame's hidden buffer name check, though. How about
make-frame-show-hidden-buffer?

On Tue, Jan 28, 2025 at 4:28 AM martin rudalics <rudalics <at> gmx.at> wrote:

> > That works for me applied to a recent master. Happy to use the buffer
> > local.
>
> We'd need a shorter name, maybe something like 'make-frame-may-show-it'.
>
> > It's unlikely to cause trouble if a user doesn't kill it, and we'll
> > understand why if they don't.
>
> Users who setq it locally or setq-default it know what they want.  Users
> who prefer let-binding it won't even notice that it's an automatically
> buffer-local variable.
>
> martin
>

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Tue, 28 Jan 2025 12:00:42 +0100

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

> Hmm. make-frame-may-show-it doesn't really capture the nature of
> make-frame's hidden buffer name check, though. How about
> make-frame-show-hidden-buffer?

In a new version I called it 'expose-hidden-buffer' so it can be used
also, for example, when switching to the previous or next buffer in a
window if we eventually want that.

martin

[expose-hidden-buffer.diff (text/x-patch, attachment)]

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

From: Ship Mints <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Tue, 28 Jan 2025 06:10:34 -0500

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

Tested and it works. Good and thank you.

I'm a heavy user of switch-to-prev-buffer-skip-regexp so that could be
helpful for people that don't make switch buffer rules as explicit as I do.

On Tue, Jan 28, 2025 at 6:00 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > Hmm. make-frame-may-show-it doesn't really capture the nature of
>  > make-frame's hidden buffer name check, though. How about
>  > make-frame-show-hidden-buffer?
>
> In a new version I called it 'expose-hidden-buffer' so it can be used
> also, for example, when switching to the previous or next buffer in a
> window if we eventually want that.
>
> martin

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 75828 <at> debbugs.gnu.org, shipmints <at> gmail.com, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Tue, 28 Jan 2025 15:54:50 +0200

> Date: Tue, 28 Jan 2025 12:00:42 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com,
>  75828 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
> +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.

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.

Thanks.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75828 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Tue, 28 Jan 2025 18:18:38 +0100

> Tested and it works. Good and thank you.

Installed, leaving out the handling of special values for the moment.

> I'm a heavy user of switch-to-prev-buffer-skip-regexp so that could be
> helpful for people that don't make switch buffer rules as explicit as I do.

As a matter of fact the obvious next client would be 'other-window'.

Whatever it is, setting 'expose-hidden-buffer' to t and having a
subsequent 'switch-to-prev-buffer' not switching to a buffer shown
previously in the window might be confusing.  Let's return to this issue
when it becomes really annoying.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75828 <at> debbugs.gnu.org, shipmints <at> gmail.com, stefankangas <at> gmail.com
Subject: Re: bug#75828: [PATCH] Correct make-frame docstring vis-a-vis
 make_frame.c
Date: Tue, 28 Jan 2025 18:18:52 +0100

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

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

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: Re: 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?

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

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

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

It concludes the bug AFAIAC.

martin

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

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

Version: 31.1

martin rudalics <rudalics <at> gmx.at> writes:

>   I see that dc6b3560e56 was installed.  Does that conclude this bug or is
>> there more to do here?
>
> It concludes the bug AFAIAC.

OK, thanks.  Closing.

Previous Next

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