Re: xterm no title (buster)
On Monday, August 10, 2020 at 7:50:04 AM UTC-4, to...@tuxteam.de wrote:
> On Mon, Aug 10, 2020 at 12:14:30PM +0200, Marc SCHAEFER wrote:
> > On Sun, Aug 09, 2020 at 09:59:12AM +0200, tomas wrote:
> > > To verify/falsify that, you might run xprop on your xterm window.
> > > The property you are looking for is called WM_NAME. You can even
> >
> > xprop | grep WM_NAME
> > WM_NAME(STRING) = "schaefer@reliand: /home/schaefer"
>
> So xterm is "setting" [1] its title correctly.
>
> > > use xprop to /set/ the window property -- this way you can be sure
> >
> > xprop -f WM_NAME 8s -set WM_NAME "toto"
>
> This is to be expected, after what you found out above.
>
> [...]
>
> Given that evidence, my guess is that the window manager is somehow
> botching the title bar dispay. Either it tries to use some non-existent
> font, or it's writing with the same background and foreground colour
> or something.
>
> Have you tried another "classic" X program? For example xmag or xeyes?
>
> This may be a hint -- either your window manager is specifically treating
> xterm in a special way, or the decorations of all "classic" X programs
> fail in the same way.
>
> Cheers
>
> [1] Of course it cannot actually "set" the title. It just can ask
> politely the window manager to do it.
While you can set the title for xmag and xeyes using the X Toolkit option "-title", it seems that OP may be doing something different. For instance, if OP's shell sends escape sequences to set the title, that could be in UTF-8, which has been a problem (a) because the original protocol uses ISO-8859-1 and (b) because the corresponding X properties have to be handled as multibyte rather than strings.
EWMH sort-of fixes the problem by providing a different set of properties which hold UTF-8. buster has xterm patch #344. The most recent fix for xterm in this area is from patch #350:
https://packages.debian.org/buster/xterm
https://invisible-island.net/xterm/xterm.log.html#xterm_350
Reply to: