bug#6418: Fwd: Another frame problem

bug#6418: Fwd: Another frame problem

[David Reitter]

Emacs
M-x speedbar

The frame showing the splash buffer now lacks a title.

(frame-parameter nil 'name) is "" for the frame (and indeed other frames that existed at the time when speedbar was started.)
Tried this on NS Emacs 23, but because of the above I don't think it's necessarily an NS bug.


Begin forwarded message:

> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
> Date: June 13, 2010 3:30:26 PM EDT
> To: aquamacs-devel@aquamacs.org
> Cc: Reitter David <david.reitter@gmail.com>
> Subject: Another frame problem
> 
> Have two files open in different frames. Then opening the speedbar makes the frame titles to disappear. This happens also in the ordinary Emacs 23.
> 
> Konrad

bug#22048: 25.1; frame title vanishes when speedbar present

[David Reitter]

X-Debbugs-CC: Konrad Podczeck <konrad.podczeck@univie.ac.at>

emacs -Q   [25.1 branch build on Mac OS X, standard NS Cocoa interface]

load some file
[observe title and icon in title bar of frame.]

M-x speedbar

observe title in original frame vanish.

Now, I have tried removing d9d383 (“more flicker fixes”), as this is the source of another bug in relation to the title/icon bar, but that doesn’t help with this bug.

The original reporter, who found this problem in Aquamacs (cc’ed), says that it’s been present for a long time.

bug#22048: 25.1; frame title vanishes when speedbar present

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Sat, 28 Nov 2015 22:28:13 -0500
> Cc: konrad podczeck <konrad.podczeck@univie.ac.at>
> 
> emacs -Q   [25.1 branch build on Mac OS X, standard NS Cocoa interface]
> 
> load some file
> [observe title and icon in title bar of frame.]
> 
> M-x speedbar
> 
> observe title in original frame vanish.

Does it happen only with speedbar as the second frame, or also if you
type "C-x 5 f SOME-FILE RET"?

Also, does it help to play with the value of frame-title-format?

Anyway, this is definitely OS X specific.  I see nothing like that
here.

bug#22048: 25.1; frame title vanishes when speedbar present

[David Reitter]

On Nov 29, 2015, at 10:36 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Does it happen only with speedbar as the second frame, or also if you
> type "C-x 5 f SOME-FILE RET”?

Only with speedbar.

> Also, does it help to play with the value of frame-title-format?

Setting it to “%b” makes the problem go away.  
frame-title-format is t by default on the Mac, which has a special (and undocumented) meaning in OS X (see nsfns.m:488).

Note that speedbar.el  has (make-local-variable 'frame-title-format).  I didn’t check what it is, but I would assume that ns_set_name() does not correctly process the frame title format for the right frame in that case.

Apart from that, what is the meaning of a buffer-local frame-title-format?  When multiple buffers are visible in a frame, does the one from the selected window apply?   x_implicitly_set_name() might not be called in the right context for frames that are not selected.

> Anyway, this is definitely OS X specific.  I see nothing like that
> here.

I don’t like the special t for frame-title-format.  I think that we would be better off checking the string for “%f” (or whatever the default outside of NS is) in x_implicitly_set_name() (in nsfns.m) and behaving accordingly. 

bug#22048: 25.1; frame title vanishes when speedbar present

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Sun, 29 Nov 2015 14:23:32 -0500
> Cc: 22048@debbugs.gnu.org,
>  konrad.podczeck@univie.ac.at
> 
> > Also, does it help to play with the value of frame-title-format?
> 
> Setting it to “%b” makes the problem go away.  
> frame-title-format is t by default on the Mac, which has a special (and undocumented) meaning in OS X (see nsfns.m:488).

Maybe you could step with a debugger into that function and see what
goes wrong there in this case.

> Note that speedbar.el  has (make-local-variable 'frame-title-format).  I didn’t check what it is, but I would assume that ns_set_name() does not correctly process the frame title format for the right frame in that case.

Most probably, yes.

> Apart from that, what is the meaning of a buffer-local frame-title-format?  When multiple buffers are visible in a frame, does the one from the selected window apply?

Yes.

> x_implicitly_set_name() might not be called in the right context for frames that are not selected.

That shouldn't happen, normally.  Displaying a frame temporarily makes
it the selected frame.

> I don’t like the special t for frame-title-format.  I think that we would be better off checking the string for “%f” (or whatever the default outside of NS is) in x_implicitly_set_name() (in nsfns.m) and behaving accordingly. 

How would the effect be different?

bug#22048: 25.1; frame title vanishes when speedbar present

[David Reitter]

On Nov 29, 2015, at 2:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> x_implicitly_set_name() might not be called in the right context for frames that are not selected.
> 
> That shouldn't happen, normally.  Displaying a frame temporarily makes
> it the selected frame.

The buffer was not current in x_consider_frame_title when x_implicitly_set_name is called.

The consequences then are obvious, as it picks up the wrong Vframe_title_format for the frame.

I believe the change below is the correct one.  It affects all platforms, though.

Are you okay with this change?  If so, I would commit it.

- David



diff --git a/src/xdisp.c b/src/xdisp.c
index 50c5518..07c771a 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11602,7 +11602,6 @@ x_consider_frame_title (Lisp_Object frame)
       display_mode_element (&it, 0, -1, -1, fmt, Qnil, false);
       len = MODE_LINE_NOPROP_LEN (title_start);
       title = mode_line_noprop_buf + title_start;
-      unbind_to (count, Qnil);
 
       /* Set the title only if it's changed.  This avoids consing in
 	 the common case where it hasn't.  (If it turns out that we've
@@ -11613,6 +11612,9 @@ x_consider_frame_title (Lisp_Object frame)
 	  || SBYTES (f->name) != len
 	  || memcmp (title, SDATA (f->name), len) != 0)
 	x_implicitly_set_name (f, make_string (title, len), Qnil);
+
+      unbind_to (count, Qnil);
+
     }
 }
 

bug#22048: 25.1; frame title vanishes when speedbar present

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Sun, 29 Nov 2015 19:14:20 -0500
> Cc: 22048@debbugs.gnu.org,
>  konrad.podczeck@univie.ac.at
> 
> >> x_implicitly_set_name() might not be called in the right context for frames 
> >> that are not selected.
> > 
> > That shouldn't happen, normally.  Displaying a frame temporarily makes
> > it the selected frame.
> 
> The buffer was not current in x_consider_frame_title when x_implicitly_set_name 
> is called.
> 
> The consequences then are obvious, as it picks up the wrong Vframe_title_format 
> for the frame.

I'm afraid I don't follow: why does ns_set_name_as_filename need the
buffer to be the current buffer?  It access that buffer through the
frame pointer:

  Lisp_Object buf = XWINDOW (f->selected_window)->contents;
  [...]
  filename = BVAR (XBUFFER (buf), filename);
  name = BVAR (XBUFFER (buf), name);

I don't see where it needs to access current_buffer.

Can you tell which part(s) of this don't work, and why?

Thanks.

bug#22048: 25.1; frame title vanishes when speedbar present

[David Reitter]

> 
> I'm afraid I don't follow: why does ns_set_name_as_filename need the
> buffer to be the current buffer?  It access that buffer through the
> frame pointer:

Yes, but x_implicitly_set_name reads Vframe_title_format directly:

if (FRAME_NS_P (f) && ((FRAME_ICONIFIED_P (f) && EQ (Vicon_title_format, Qt))
                         || EQ (Vframe_title_format, Qt)))

It picks up the wrong value there.  Based on that, I think ns_set_name_as_filename isn’t called at all because it reads the value meant for the speedbar frame. I didn’t bother to look at what then happens in ns_set_name and ns_set_name_internal.

We can of course use BVAR to read Vframe_title_format as a smaller change, but unless you tell me otherwise, it seems to make more sense to have the right buffer current when calling the port-specific routing.

(By the way, I first tried to do this in x_implicitly_set_name:

set_buffer_internal_1
	(XBUFFER (XWINDOW (f->selected_window)->contents));

which works, but I find that the more dangerous change as the current buffer is permanently changed.

bug#22048: 25.1; frame title vanishes when speedbar present

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Mon, 30 Nov 2015 11:20:00 -0500
> Cc: 22048@debbugs.gnu.org,
>  konrad.podczeck@univie.ac.at
> 
> > 
> > I'm afraid I don't follow: why does ns_set_name_as_filename need the
> > buffer to be the current buffer?  It access that buffer through the
> > frame pointer:
> 
> Yes, but x_implicitly_set_name reads Vframe_title_format directly:
> 
> if (FRAME_NS_P (f) && ((FRAME_ICONIFIED_P (f) && EQ (Vicon_title_format, Qt))
>                          || EQ (Vframe_title_format, Qt)))
> 
> It picks up the wrong value there.  Based on that, I think ns_set_name_as_filename isn’t called at all because it reads the value meant for the speedbar frame. I didn’t bother to look at what then happens in ns_set_name and ns_set_name_internal.

Sorry, I'm still confused: Vframe_title_format is a global variable,
it's neither buffer-local not frame-local, AFAIK.  So how come the
wrong value is picked up by x_implicitly_set_name?

> (By the way, I first tried to do this in x_implicitly_set_name:
> 
> set_buffer_internal_1
> 	(XBUFFER (XWINDOW (f->selected_window)->contents));
> 
> which works, but I find that the more dangerous change as the current buffer is permanently changed.

Not sure how the current buffer enters the picture here.

bug#22048: 25.1; frame title vanishes when speedbar present

[martin rudalics]

 > Sorry, I'm still confused: Vframe_title_format is a global variable,
 > it's neither buffer-local not frame-local, AFAIK.  So how come the
 > wrong value is picked up by x_implicitly_set_name?

Because ‘speedbar-mode’ does

(make-local-variable 'frame-title-format)

martin

bug#22048: 25.1; frame title vanishes when speedbar present

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

Speedbar makes it a loca variable to set the frame title of its own frame to "speedbar".



—
A terse message sent with my phone

On Mon, Nov 30, 2015 at 1:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: David Reitter <david.reitter@gmail.com>
>> Date: Mon, 30 Nov 2015 11:20:00 -0500
>> Cc: 22048@debbugs.gnu.org,
>>  konrad.podczeck@univie.ac.at
>> 
>> > 
>> > I'm afraid I don't follow: why does ns_set_name_as_filename need the
>> > buffer to be the current buffer?  It access that buffer through the
>> > frame pointer:
>> 
>> Yes, but x_implicitly_set_name reads Vframe_title_format directly:
>> 
>> if (FRAME_NS_P (f) && ((FRAME_ICONIFIED_P (f) && EQ (Vicon_title_format, Qt))
>>                          || EQ (Vframe_title_format, Qt)))
>> 
>> It picks up the wrong value there.  Based on that, I think ns_set_name_as_filename isn’t called at all because it reads the value meant for the speedbar frame. I didn’t bother to look at what then happens in ns_set_name and ns_set_name_internal.
> Sorry, I'm still confused: Vframe_title_format is a global variable,
> it's neither buffer-local not frame-local, AFAIK.  So how come the
> wrong value is picked up by x_implicitly_set_name?
>> (By the way, I first tried to do this in x_implicitly_set_name:
>> 
>> set_buffer_internal_1
>> 	(XBUFFER (XWINDOW (f->selected_window)->contents));
>> 
>> which works, but I find that the more dangerous change as the current buffer is permanently changed.
> Not sure how the current buffer enters the picture here.

[-- Attachment #2: Type: text/html, Size: 2051 bytes --]

bug#22048: 25.1; frame title vanishes when speedbar present

[Eli Zaretskii]

> Date: Mon, 30 Nov 2015 10:20:04 -0800 (PST)
> From: "David Reitter" <david.reitter@gmail.com>
> Cc: 22048@debbugs.gnu.org, konrad.podczeck@univie.ac.at
> 
> Speedbar makes it a loca variable to set the frame title of its own frame to
> "speedbar".

Right.  So then calling buffer_local_value in x_implicitly_set_name
should produce the value for the buffer of the frame's selected
window.  Would that solve the problem?

(I'm trying to avoid extending the effect of temporarily switching to
the frame's selected window, because that would make the change local
to the NS port, so we can more easily decide to install it on the
emacs-25 branch.)

bug#22048: 25.1; frame title vanishes when speedbar present

[Eli Zaretskii]

> Date: Mon, 30 Nov 2015 19:16:29 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: konrad.podczeck@univie.ac.at, 22048@debbugs.gnu.org
> 
>  > Sorry, I'm still confused: Vframe_title_format is a global variable,
>  > it's neither buffer-local not frame-local, AFAIK.  So how come the
>  > wrong value is picked up by x_implicitly_set_name?
> 
> Because ‘speedbar-mode’ does
> 
> (make-local-variable 'frame-title-format)

Thanks.

bug#22048: 25.1; frame title vanishes when speedbar present

[David Reitter]

On Nov 30, 2015, at 1:33 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Mon, 30 Nov 2015 10:20:04 -0800 (PST)
>> From: "David Reitter" <david.reitter@gmail.com>
>> Cc: 22048@debbugs.gnu.org, konrad.podczeck@univie.ac.at
>> 
>> Speedbar makes it a loca variable to set the frame title of its own frame to
>> "speedbar".
> 
> Right.  So then calling buffer_local_value in x_implicitly_set_name
> should produce the value for the buffer of the frame's selected
> window.  Would that solve the problem?

Yes, for the NS port only of course.  I don’t know if there are such problems in other ports.
I cursorily checked the windows port and didn’t see any use of the variable.

> (I'm trying to avoid extending the effect of temporarily switching to
> the frame's selected window, because that would make the change local
> to the NS port, so we can more easily decide to install it on the
> emacs-25 branch.)

Yes, I asked precisely because it is a wider-ranging change that I thought and think is, in principle, the right fix.

Anyway, I have committed a change for nsfns.m.

This should be fixed.  Thanks, Konrad, for reporting this. 

bug#22048: 25.1; frame title vanishes when speedbar present

[martin rudalics]

 > Anyway, I have committed a change for nsfns.m.
 >
 > This should be fixed.

You might consider closing bug#6418 too now.

martin

bug#6418: Fwd: bug#22048: 25.1; frame title vanishes when speedbar present

[David Reitter]

Agreed.

> Begin forwarded message:
> 
> From: martin rudalics <rudalics@gmx.at>
> Date: December 4, 2015 at 2:23:40 PM EST
> To: 22048@debbugs.gnu.org, david.reitter@gmail.com
> Subject: Re: bug#22048: 25.1; frame title vanishes when speedbar present
> 
> > Anyway, I have committed a change for nsfns.m.
> >
> > This should be fixed.
> 
> You might consider closing bug#6418 too now.
> 
> martin