bug#49932: 28.0.50; Error in GUI frames when xterm-set-window-title is set

bug#49932: 28.0.50; Error in GUI frames when xterm-set-window-title is set

[Knut Anders Hatlen]

1. Start GUI Emacs with 'emacs -Q'.

2. Evaluate:

  (progn
    (setq xterm-set-window-title t)
    (server-start))

3. In a terminal, run 'emacsclient -t'.

4. Switch to the GUI instance started in 1. Observe that the following
   error is raised:

  Error in post-command-hook (xterm-set-window-title): (error "Device 1
  is not a termcap terminal device")

5. Start a new GUI frame with 'emacsclient -c', and again observe that
   "Device 1 is not a termcap terminal device" is reported.

I believe xterm-set-window-title should not affect GUI frames.


In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-08-07 built on dell
Repository revision: adab672edb3fad0851a52e3b6ccf3ac31c80b025
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-native-compilation --with-json --with-xml2
 'CFLAGS=-O2 -flto -march=native' LDFLAGS=-flto'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

Important settings:
  value of $LANG: nn_NO.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail comp comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra
help-mode seq cl-loaddefs cl-lib rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils term/xterm xterm byte-opt gv bytecomp byte-compile
cconv server iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar
mouse jit-lock font-lock syntax font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice button loaddefs faces
cus-face macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 97323 10174)
 (symbols 48 8073 1)
 (strings 32 23185 1925)
 (string-bytes 1 785139)
 (vectors 16 17773)
 (vector-slots 8 349322 14036)
 (floats 8 44 33)
 (intervals 56 236 0)
 (buffers 992 14))

bug#49932: 28.0.50; Error in GUI frames when xterm-set-window-title is set

[Lars Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> 5. Start a new GUI frame with 'emacsclient -c', and again observe that
>    "Device 1 is not a termcap terminal device" is reported.
>
> I believe xterm-set-window-title should not affect GUI frames.

The problem seems to be:

(defun xterm-set-window-title (&optional terminal)
  "Set the window title of the Xterm TERMINAL.
The title is constructed from `frame-title-format'."
  (send-string-to-terminal
   (format "\e]2;%s\a" (format-mode-line frame-title-format))
   terminal))

Debugger entered: nil
  xterm-set-window-title()
  xterm--init-frame-title()
  xterm--init()
  terminal-init-xterm()
  tty-run-terminal-initialization(#<frame F11 0x5631310b99f0> nil t)
  tty-create-frame-with-faces(((client . #<process server <15>>) (environment "_=./$
  #f(compiled-function (params) #<bytecode -0x1d5fbf53102d34d1>)(((client . #<proce$
  apply(#f(compiled-function (params) #<bytecode -0x1d5fbf53102d34d1>) ((client . #$
  frame-creation-function(((client . #<process server <15>>) (environment "_=./li

That is, it's not specifying what terminal to set the title in -- so
it's set in all terminals, no matter what, all the time?  That is:

  (add-hook 'post-command-hook 'xterm-set-window-title)
  (add-hook 'minibuffer-exit-hook 'xterm-set-window-title))

Which just seems less than optimal in many ways -- running this from
post-command-hook seems pretty excessive?  But...

Anyway, I've now just made the function not do anything on graphical
displays, which should make the problem go away, but perhaps this should
be implemented a different way?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49932: 28.0.50; Error in GUI frames when xterm-set-window-title is set

[Knut Anders Hatlen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> 5. Start a new GUI frame with 'emacsclient -c', and again observe that
>>    "Device 1 is not a termcap terminal device" is reported.
>>
>> I believe xterm-set-window-title should not affect GUI frames.
>
> The problem seems to be:
>
> (defun xterm-set-window-title (&optional terminal)
>   "Set the window title of the Xterm TERMINAL.
> The title is constructed from `frame-title-format'."
>   (send-string-to-terminal
>    (format "\e]2;%s\a" (format-mode-line frame-title-format))
>    terminal))
>
> Debugger entered: nil
>   xterm-set-window-title()
>   xterm--init-frame-title()
>   xterm--init()
>   terminal-init-xterm()
>   tty-run-terminal-initialization(#<frame F11 0x5631310b99f0> nil t)
>   tty-create-frame-with-faces(((client . #<process server <15>>) (environment "_=./$
>   #f(compiled-function (params) #<bytecode -0x1d5fbf53102d34d1>)(((client . #<proce$
>   apply(#f(compiled-function (params) #<bytecode -0x1d5fbf53102d34d1>) ((client . #$
>   frame-creation-function(((client . #<process server <15>>) (environment "_=./li
>
> That is, it's not specifying what terminal to set the title in -- so
> it's set in all terminals, no matter what, all the time?  That is:
>
>   (add-hook 'post-command-hook 'xterm-set-window-title)
>   (add-hook 'minibuffer-exit-hook 'xterm-set-window-title))
>
> Which just seems less than optimal in many ways -- running this from
> post-command-hook seems pretty excessive?  But...
>
> Anyway, I've now just made the function not do anything on graphical
> displays, which should make the problem go away, but perhaps this should
> be implemented a different way?

Thanks for the quick fix, Lars. I guess you're right that it's not
ideal. Some kind of generic set-frame-title mechanism that both
graphical frames and tty frames could hook into sounds better. (I don't
know the code well enough to suggest anything concrete. And I haven't
had xterm-set-window-title enabled long enough to have noticed other
problems with the current approach.)

But in any case your patch seems to fix the immediate problem, so thanks
for that.

-- 
Knut Anders