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