GNU bug report logs - #28340
26.0.50; xterm frame titles

Previous Next

Package: emacs;

Reported by: Mark Oteiza <mvoteiza <at> udel.edu>

Date: Sun, 3 Sep 2017 21:38:01 UTC

Severity: wishlist

Found in version 26.0.50

Done: Mark Oteiza <mvoteiza <at> udel.edu>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mark Oteiza <mvoteiza <at> udel.edu>
Cc: 28340 <at> debbugs.gnu.org
Subject: Re: bug#28340: 26.0.50; xterm frame titles
Date: Wed, 20 Sep 2017 10:47:26 +0300
> Date: Mon, 11 Sep 2017 21:21:22 -0400
> From: Mark Oteiza <mvoteiza <at> udel.edu>
> Cc: 28340 <at> debbugs.gnu.org
> 
> > Maybe one of the hooks provided by server.el would fit the bill?
> 
> Nope, none of those appear relevant, and hooking into them does nothing
> apparent.  Even doing the following, I get the title as the selected
> buffer in the previously selected frame.
> 
> Messaging (frame-list) in xterm-test shows that the car of the list is
> always the new frame, but still the frame title is incorrect--a new
> frame created by emacsclient -t ends up on the scratch buffer.  I say
> "ends up" because sometimes I see another buffer flash before I see the
> scratch buffer.  This all seems a little buggy to me, but I know
> Bug#18137 and its ancestors were tough.

What about window-configuration-change-hook, does that help?  You
could set some flag in after-make-frame-functions, and then test and
reset that flag in window-configuration-change-hook, when you see that
a buffer is switched in the frame.  Would that work?




This bug report was last modified 7 years and 286 days ago.

Previous Next


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