Frame title problem

Frame title problem

[Stephen Berman]

The X Window title bars of my Emacs 24 builds have an oddity: no matter
what the value of frame-title-format is (including nil), the title bar
always displays the string " <@escher.home> " at the end (unless more
than one Emacs frame is open, in which case "<2>" follows that string in
one of the frames), where "escher.home" is the value of system-name.
However, I only see this frame title appendage under KDE, not under
icewm or twm (these are the only WM's currently installed on my system).
And, while I see this with an Emacs 24 build of 2010-09-08, I do not see
it with a 23.1.91 build of 2010-01-28 (the only 23.2 pretest build I
have).  These two builds differ in GTK+ version: 2.18.1 for the earlier
vs. 2.18.6 for the later builds.  But I also have an Emacs 23.1 built
with GTK+ 2.18.6 by openSUSE on the same system (I'm running 11.2 and
KDE 4.5.2), and this 23.1 build does not have the frame title appendage.
So this seems to be due to some interaction between Emacs 24 and
KDE/GTK+ (perhaps involving the gtk-qt engine), since I haven't observed
this with any application beside Emacs 24.  Do any of you have an idea
what could be causing this problem, or a suggestion how I could try to
track it down?

Steve Berman

Re: Frame title problem

[Julien Danjou]

On Fri, Nov 05 2010, Stephen Berman wrote:

> suggestion how I could try to
> track it down?

Run xprop and click on the Emacs window, then look for WM_NAME and
_NET_WM_NAME.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Frame title problem

[Stephen Berman]

On Fri, 05 Nov 2010 17:12:25 +0100 Julien Danjou <julien@danjou.info> wrote:

> On Fri, Nov 05 2010, Stephen Berman wrote:
>
>> suggestion how I could try to
>> track it down?
>
> Run xprop and click on the Emacs window, then look for WM_NAME and
> _NET_WM_NAME.

Thanks.  This is what xprop returns:

WM_NAME(STRING) = "emacs@escher.home"
_NET_WM_NAME(UTF8_STRING) = 0x65, 0x6d, 0x61, 0x63, 0x73, 0x40, 0x65, 0x73, 0x63, 0x68, 0x65, 0x72, 0x2e, 0x68, 0x6f, 0x6d, 0x65

which is just the default value of frame-title-format, i.e., there is no
sign of the mysterious appendage " <@escher.home> " in the xprop
output.  What does that mean?

Steve Berman

Re: Frame title problem

[Andreas Schwab]

Stephen Berman <stephen.berman@gmx.net> writes:

> which is just the default value of frame-title-format, i.e., there is no
> sign of the mysterious appendage " <@escher.home> " in the xprop
> output.  What does that mean?

Look for WM_CLIENT_MACHINE, if that doesn't match hostname then kwin
assumes the client is remote and appends the marker to the title.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Frame title problem

[Stephen Berman]

On Sat, 06 Nov 2010 09:17:16 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> which is just the default value of frame-title-format, i.e., there is no
>> sign of the mysterious appendage " <@escher.home> " in the xprop
>> output.  What does that mean?
>
> Look for WM_CLIENT_MACHINE, if that doesn't match hostname then kwin
> assumes the client is remote and appends the marker to the title.

Thanks, I didn't know that.

WM_CLIENT_MACHINE(STRING) = "escher.home"

When I use xprop on my Emacs 23.1.91 build or on the Emacs 23.1 built by
openSUSE, I get

WM_CLIENT_MACHINE(STRING) = "escher"

On all three Emacsen system-name is "escher.home".  $HOST and $HOSTNAME
are "escher".  In /etc/hosts "escher.home" is the
Full-Qualified-Hostname and "escher" is the Short-Hostname.  So why is
WM_CLIENT_MACHINE the former instead of the latter on Emacs 24?

Steve Berman

Re: Frame title problem

[Jan Djärv]

The 23 branch does not set WM_CLIENT_MACHINE, but trunk does set it to 
system-name.  See bug 5828 (_NET_WM_PID is useless without WM_CLIENT_MACHINE).

KWin should be able to figure out that escher and escher.home is the same 
machine, IMHO.

	Jan D.


Stephen Berman skrev 2010-11-06 13.29:
> On Sat, 06 Nov 2010 09:17:16 +0100 Andreas Schwab<schwab@linux-m68k.org>  wrote:
>
>> Stephen Berman<stephen.berman@gmx.net>  writes:
>>
>>> which is just the default value of frame-title-format, i.e., there is no
>>> sign of the mysterious appendage "<@escher.home>  " in the xprop
>>> output.  What does that mean?
>>
>> Look for WM_CLIENT_MACHINE, if that doesn't match hostname then kwin
>> assumes the client is remote and appends the marker to the title.
>
> Thanks, I didn't know that.
>
> WM_CLIENT_MACHINE(STRING) = "escher.home"
>
> When I use xprop on my Emacs 23.1.91 build or on the Emacs 23.1 built by
> openSUSE, I get
>
> WM_CLIENT_MACHINE(STRING) = "escher"
>
> On all three Emacsen system-name is "escher.home".  $HOST and $HOSTNAME
> are "escher".  In /etc/hosts "escher.home" is the
> Full-Qualified-Hostname and "escher" is the Short-Hostname.  So why is
> WM_CLIENT_MACHINE the former instead of the latter on Emacs 24?
>
> Steve Berman
>

Re: Frame title problem

[Stephen Berman]

On Sat, 06 Nov 2010 18:05:22 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:

> The 23 branch does not set WM_CLIENT_MACHINE, but trunk does set it to
> system-name.  See bug 5828 (_NET_WM_PID is useless without WM_CLIENT_MACHINE).

Thanks for the explanation and the pointer.

> KWin should be able to figure out that escher and escher.home is the same
> machine, IMHO.

I suppose so, though it seems odd that either no other application (at
least that I've been using) sets WM_CLIENT_MACHINE or they do it in a
way that kwin doesn't think they're remote...

Steve Berman

Re: Frame title problem

[Jan Djärv]

They probably just use hostname, but Emacs goes through the motions (i.e. 
gethostbyname) to get the fqdn and that ends up in system-name.

	Jan D.


Stephen Berman skrev 2010-11-06 20.44:
> On Sat, 06 Nov 2010 18:05:22 +0100 Jan Djärv<jan.h.d@swipnet.se>  wrote:
>
>> The 23 branch does not set WM_CLIENT_MACHINE, but trunk does set it to
>> system-name.  See bug 5828 (_NET_WM_PID is useless without WM_CLIENT_MACHINE).
>
> Thanks for the explanation and the pointer.
>
>> KWin should be able to figure out that escher and escher.home is the same
>> machine, IMHO.
>
> I suppose so, though it seems odd that either no other application (at
> least that I've been using) sets WM_CLIENT_MACHINE or they do it in a
> way that kwin doesn't think they're remote...
>
> Steve Berman
>

Re: Frame title problem

[Stephen Berman]

On Sat, 06 Nov 2010 21:14:56 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:

> They probably just use hostname, but Emacs goes through the motions
> (i.e. gethostbyname) to get the fqdn and that ends up in system-name.

I reported this to the KDE bugtracker
(https://bugs.kde.org/show_bug.cgi?id=256258) and got this response:

> --- Comment #1 from Martin Gräßlin <kde martin-graesslin com>  2010-11-06 22:53:24 ---
> This looks like an emacs bug to me. Please see the standard for it: 
> http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.9
>
>> The client should set the WM_CLIENT_MACHINE property (of one of the
>> TEXT types) to a string that forms the name of the machine running
>> the client as seen from the machine running the server.
>
> I assume for the server it will just be escher and not the fqdn. It is
> rather unusual to identify the local machine with a fqdn.
>
> Anyway it's not a bug in kwin, but a regression in emacs. If they
> change something like that, they should revert and not tell window
> managers to adjust their code.

Steve Berman

Re: Frame title problem

[Jan Djärv]

So the shortname is known to the X Server but the fqdn is not?  This is so 
naive.  The identity of a machine is not so simple as kwin people would wish, 
but I guess they are too lazy to fix their bad code.  So I changed Emacs so it 
lets the X libs set WM_CLIENT_MACHINE.  Please try it and see if it works.
If not, I guess Xorg and KDE have to battle it out.

	Jan D.


Stephen Berman skrev 2010-11-06 23.06:
> On Sat, 06 Nov 2010 21:14:56 +0100 Jan Djärv<jan.h.d@swipnet.se>  wrote:
>
>> They probably just use hostname, but Emacs goes through the motions
>> (i.e. gethostbyname) to get the fqdn and that ends up in system-name.
>
> I reported this to the KDE bugtracker
> (https://bugs.kde.org/show_bug.cgi?id=256258) and got this response:
>
>> --- Comment #1 from Martin Gräßlin<kde martin-graesslin com>   2010-11-06 22:53:24 ---
>> This looks like an emacs bug to me. Please see the standard for it:
>> http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.9
>>
>>> The client should set the WM_CLIENT_MACHINE property (of one of the
>>> TEXT types) to a string that forms the name of the machine running
>>> the client as seen from the machine running the server.
>>
>> I assume for the server it will just be escher and not the fqdn. It is
>> rather unusual to identify the local machine with a fqdn.
>>
>> Anyway it's not a bug in kwin, but a regression in emacs. If they
>> change something like that, they should revert and not tell window
>> managers to adjust their code.
>
> Steve Berman

Re: Frame title problem

[Stephen J. Turnbull]

Jan Djärv writes:

 > So the shortname is known to the X Server but the fqdn is not?

No, AFAIK the X server doesn't know anything about this; it never
inspects window properties, does it?  It's the window manager (another
client) that is obtaining this information.

 > This is so naive.  The identity of a machine is not so simple as
 > kwin people would wish, but I guess they are too lazy to fix their
 > bad code.

Sorry, kwin is right and you're wrong.  Martin G. is being a jerk and
gave the wrong reason, though.  The right one is the definition of
"client property", especially the last sentence:

    4.1.2. Client Properties

    Once the client has one or more top-level windows, it should place
    properties on those windows to inform the window manager of the
    behavior that the client desires. Window managers will assume
    values they find convenient for any of these properties that are
    not supplied; clients that depend on particular values must
    explicitly supply them. The window manager will not change
    properties written by the client.

So it's very definitely *not* the kwin people's problem to clean up
disagreements among clients.  (In theory they could parse the property
and use only the parts they like, but that would Really Suck IMHO.)

Those disagreements indicate a problem with the standard (what else is
new?)  In this case there is no rationale given for WM_CLIENT_MACHINE
and the definition ambiguous (at the very least, "localhost",
`hostname -s`, and the canonical domain name are plausible), so it's
not clear what this is good for, and no way to judge whether the
default implementation in the X.org version of Xlib makes sense.

 > So I changed Emacs so it lets the X libs set WM_CLIENT_MACHINE.

Given the quality of the standard, the only use I can think of is as a
heuristic for "readable host name" in frame decorations.  If so and
the Xlibs will do this for you, this is the Right Thing.

If anybody actually cares, you could make this a user option in Emacs.
But at this point I am almost certain you shouldn't do more than leave
a comment to the effect that `system-name' is plausible too and could
be an option.

Re: Frame title problem

[Jan Djärv]

Stephen J. Turnbull skrev 2010-11-07 15.52:
>   >  So I changed Emacs so it lets the X libs set WM_CLIENT_MACHINE.
>
> Given the quality of the standard, the only use I can think of is as a
> heuristic for "readable host name" in frame decorations.  If so and
> the Xlibs will do this for you, this is the Right Thing.
>

WM_CLIENT_MACHINE is used by managers to kill off bad clients when they don't 
respond.  It uses _NET_WM_PID and WM_CLIENT_MACHINE to determine if the pid is 
local.

	Jan D.

Re: Frame title problem

[Stephen J. Turnbull]

Jan Djärv writes:
 > 
 > 
 > Stephen J. Turnbull skrev 2010-11-07 15.52:
 > >   >  So I changed Emacs so it lets the X libs set WM_CLIENT_MACHINE.
 > >
 > > Given the quality of the standard, the only use I can think of is as a
 > > heuristic for "readable host name" in frame decorations.  If so and
 > > the Xlibs will do this for you, this is the Right Thing.
 > >
 > 
 > WM_CLIENT_MACHINE is used by managers to kill off bad clients when they don't 
 > respond.  It uses _NET_WM_PID and WM_CLIENT_MACHINE to determine if the pid is 
 > local.

Too bad the WM, then, because as you pointed out WM_CLIENT_MACHINE is
not defined in a way that's very useful for that purpose.  As a client
property, it could be almost anything.  Furthermore, it shouldn't be a
client property; really, this should be transparent to the client, set
in one of the shell widgets.

Anyway, this shouldn't matter to Emacs, Emacs never infloops, right? ;-)

Re: Frame title problem

[Stephen Berman]

On Sun, 07 Nov 2010 12:28:48 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:

> So the shortname is known to the X Server but the fqdn is not?  This is so
> naive.  The identity of a machine is not so simple as kwin people would wish,
> but I guess they are too lazy to fix their bad code.  So I changed Emacs so it
> lets the X libs set WM_CLIENT_MACHINE.  Please try it and see if it works.

It does, thanks!

Steve Berman

Re: Frame title problem

[Jan Djärv]

Did you try choosing a theme that doesn't use gtk-engine?

     Jan D.

5 nov 2010 kl. 15:55 skrev Stephen Berman <stephen.berman@gmx.net>:

> The X Window title bars of my Emacs 24 builds have an oddity: no matter
> what the value of frame-title-format is (including nil), the title bar
> always displays the string " <@escher.home> " at the end (unless more
> than one Emacs frame is open, in which case "<2>" follows that string in
> one of the frames), where "escher.home" is the value of system-name.
> However, I only see this frame title appendage under KDE, not under
> icewm or twm (these are the only WM's currently installed on my system).
> And, while I see this with an Emacs 24 build of 2010-09-08, I do not see
> it with a 23.1.91 build of 2010-01-28 (the only 23.2 pretest build I
> have).  These two builds differ in GTK+ version: 2.18.1 for the earlier
> vs. 2.18.6 for the later builds.  But I also have an Emacs 23.1 built
> with GTK+ 2.18.6 by openSUSE on the same system (I'm running 11.2 and
> KDE 4.5.2), and this 23.1 build does not have the frame title appendage.
> So this seems to be due to some interaction between Emacs 24 and
> KDE/GTK+ (perhaps involving the gtk-qt engine), since I haven't observed
> this with any application beside Emacs 24.  Do any of you have an idea
> what could be causing this problem, or a suggestion how I could try to
> track it down?
> 
> Steve Berman
>