Version: unspecified (using KDE 4.5.2) OS: Linux The window title of Emacs 24 (built from Emacs bzr repository sources) always ends in the string " <@escher.home> ", which I was told means that kwin identifies the application as running on a remote machine; however, it is running locally. This is the bug; what follows are some analysis and hypotheses. I reported this problem to the Emacs developers list (see http://permalink.gmane.org/gmane.emacs.devel/132402 and followups) and learned that Emacs 24 (unlike earlier versions) sets WM_CLIENT_MACHINE by gethostbyname(), which returns the FQDN, which is "escher.home". The developer surmised that kwin uses the hostname, which is just "escher" (both the FQDN and the short name are listed in /etc/hosts). So it appears that kwin does not recognize that "escher.home" and "escher" refer to the same machine. Would it be possible for kwin to check /etc/hosts or to use gethostbyname()? Reproducible: Always Steps to Reproduce: Start a recent build of Emacs 24 as local X application under kwin. The window title can be changed within the running Emacs by setting the variable frame-title-format, e.g. to some string value, or also to nil (no title). Actual Results: Whatever the value of frame-title-format is set to, the window title ends in the string " <@full.hostname> ", where "full.hostname" is the full hostname appearing in /etc/hosts, not the short variant. Expected Results: The window title should not end in " <@full.hostname> ", since the application is running locally.
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.
I assume this is fixed with the following commit: commit c24ea2b4aac214ce29afc013cc037c110a24aa12 Author: Luboš Luňák <l.lunak@suse.cz> Date: Fri Mar 4 16:22:23 2011 +0100 do not show hostname in titlebar if it's FQDN of localhost If not fixed in 4.6.2 please reopen
Created attachment 71290 [details] Assembly hostname according to the DNS instead of NIS When I wanted to incorporate to Trinity patch from your commit c24ea2b4, I found that it does not work properly. To build the full qualified host name is used NIS domain instead of the DNS domain. NIS domain but may either be different or none at all. Therefore I have prepared a new patch - see commit 9e3f8a7f in Trinity.
Please, how can I reopen this bug? It is not resolved / fixed.
@Slávek The trinity patch is likely borrowed from the kwin patch Martin mentioned. The major difference is the usage of the POSIX confirm getaddrinfo() while the kwin code includes the BSD/Linux only getdomainname() That said: deactivating title trimming in the bespin deco (which i maybe really should move upstream? /advert), a see this in emacs as well, having a look into the resolution now.
Sorry to say, but that's an emacs thing, the hostname is in the set caption and *not* added by kwin (it's also present the very same way in _every_ WM i tested - and I've quite some flying around) The host is properly resolved (and also simple in my case) and the caption is "emacs@hostname" and *not* "emacs<@hostname>" So unless you hit this with sth. that is not the "I-am-special" emacs, the only valid bug in this regard would be the posix incompliance (what does not affect you unless you're on some Oracle OS and would not change the visual outcome either)
@Slavik You're however in general absolutely right about NIS ./. DNS, ie. getdomainname being isuffiencient in that case, but that's actually a completely different bug -> please refile and ideally provide a patch at git.reviewboard.kde.org out of curiosity: local bind or sth. OS specific?
The patch, which is used as a solution mentions LibreOffice. And that LibreOffice is what the patch not resolved. In other words, the original patch from KDE4.x not fulfilling its purpose - not even a little bit. Comment I added to this issue because, at this issue is patch listed as its solution.
it's not the same bug and cannot be since the insufficient patch is newer than the bug. you pointed the issues with getdomainname under a certain scenario, but that issue could not have possibly existed when this bug was filed so we cannot legally resolve DNS/NIS by closing this bug. why hijacking a different dead bug is a bad idea has nicely been illustrated within the last hour when i wasted time on checking emacs ;-)
Bad that Martin improperly stated the patch from Lukáš for this bug. Otherwise I would my comment to this error not written. I just created an account on the Review Board to be able to put a patch to Review Board... For first I must a bit to learn Review Board.
> Bad that Martin improperly stated the patch from Lukáš for this bug. > Otherwise I would my comment to this error not written. Ah I don't use emacs and the bug looked similar :-) > > I just created an account on the Review Board to be able to put a patch to > Review Board... For first I must a bit to learn Review Board. easiest way is with post-review especially in combination with git.
(In reply to comment #10) > Bad that Martin improperly stated the patch from Lukáš for this bug. Actually sounds like a reasonable assumption - the reporter even might have spotted the total absence of a usable hostname resolution. > Otherwise I would my comment to this error not written. General rule of thumb: unless there's a commit message that closes the bug and you can say that this committed fix does actually not fix that very bug - just open a new bug, pointing out the issue with the status quo. Reviving bugs simply doesn't work. > I just created an account on the Review Board to be able to put a patch to > Review Board... For first I must a bit to learn Review Board. It's not very hard, you need an updated git branch with the desired patch on to of the origins HEAD, then you can just add a new review (component is kde-workspace) of that diff.
(In reply to comment #12) > > Otherwise I would my comment to this error not written. > General rule of thumb: unless there's a commit message that closes the bug > and you can say that this committed fix does actually not fix that very bug > - just open a new bug, pointing out the issue with the status quo. > > Reviving bugs simply doesn't work. Aha - I'm used to from other bugzilla, where reopening commonly used. After all, that's why I asked this before, as it does here. > > > I just created an account on the Review Board to be able to put a patch to > > Review Board... For first I must a bit to learn Review Board. > It's not very hard, you need an updated git branch with the desired patch on > to of the origins HEAD, then you can just add a new review (component is > kde-workspace) of that diff. Well, simple - but I have complete GIT clone Trinity, but neither piece KDE4.x. Therefore, I hope that you will be able to adapt the patch yourself. The fact that you want me to set the patch on a silver platter, it's more complicated for me.
(In reply to comment #13) > Aha - I'm used to from other bugzilla, where reopening commonly used. After > all, that's why I asked this before, as it does here. Re-opening does work, reviving a 18 months old bug rather not ;-) > KDE4.x. Therefore, I hope that you will be able to adapt the patch yourself. Sure, no problem. > The fact that you want me to set the patch on a silver platter, it's more > complicated for me. It wasn't thought like that but rather a) get in more committers b) have your name under the patch
Reopening because this bug is NOT fixed and never was, see the discussion.
there's a more precise bug available, this one's incredibly ambiguous because emacs sets the hostname in the title anyway and that will not be fixed with the fqdm check either. if that's your problem, you can mark it as won't fix and contact emacs authors. *** This bug has been marked as a duplicate of bug 308391 ***