bug#28340: 26.0.50; xterm frame titles

[Mark Oteiza <mvoteiza@udel.edu>]

On 04/09/17 at 07:16am, Eli Zaretskii wrote:
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Date: Sun, 03 Sep 2017 17:37:24 -0400
> > I tacked setting window/iconified window titles into term/xterm.el, but
>
> Thanks.  This needs a NEWS entry, and I think there should be a
> defcustom to turn this off, for those who'd like the default title
> provided by xterm.

Ok.

> > found a quirk I suspect is related to Bug#18137 (which refers to
> > 42fe2e88d and Bug#15025).  Because clients don't always have focus,
> > opening a new client won't trigger hooks that I would think trigger,
> > perhaps even after-make-frame-functions or window-size-change-functions.
>
> 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.

(defun xterm--init-frame-title ()
  "Terminal initialization for `gui-set-selection'."
  (xterm-set-window-title)
  (add-hook 'after-make-frame-functions 'xterm-test)
  (add-hook 'server-switch-hook 'xterm-test)
  ;; (add-hook 'window-size-change-functions 'xterm-set-window-title)
  ;; (add-hook 'post-command-hook 'xterm-set-window-title)
  ;; (add-hook 'minibuffer-exit-hook 'xterm-set-window-title)
  )

(defun xterm-test (&optional frame)
  (select-frame (car (frame-list)))
  (xterm-set-window-title frame))