bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Knut Anders Hatlen
Subject: bug#49932: 28.0.50; Error in GUI frames when xterm-set-window-title is set
Date: Mon, 09 Aug 2021 20:39:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]