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

["David Reitter" <david.reitter@gmail.com>]

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