After the update of x11/xterm to 350 I get a strange bug. I use x11-wm/windowmaker as windowmanager. The miniwindows in WM have a titlebar with the title of the running program in it. But in case of xterm applications these titles disappear, resulting in an empty titlebar of the miniwindow. The bug appears only though, when the running application is using another program to open something. I.e. when opening a jpg file in Alpine with feh, or when opening a PDF in Midnight Commander. After opening a file with the "helper" program, the title in the titlebar of the miniwindow disappears. Also Emacs (nox) doesn't have a title in the miniwindow at all after the update to 350. I'm not sure if this is a WindowMaker or an Xterm bug, but since it happened after the update of Xterm to 350 I'm trying here first.
I made fixes for title-string in 348-349, but 350's ok (I thought). Unrelated, there's a problem with Xft + double-buffering which I've been working on (and have fixed the parts I can reproduce).
For the record: there are no problems with the titles of windows itself, but only with the titles of the miniwindows in WindowMaker. So I'm not sure if it's a bug in Xterm or a bug in WindowMaker that's been triggered by a change in Xterm.
A screenshot would help (I don't know what "miniwindow" might be, related to xterm).
Created attachment 209162 [details] screenshot A miniwindow in WM is a minimized window, in my screenshot the icons with the name of the executable above it (icons below/left). Notice that the titlebars of the icons of Emacs, Lynx and Midnight Commander are empty.
I can reproduce the effect with emacs (using the FreeBSD package). My usual self-build works; I'll compare the configure options to see what problem the package runs into (and fix xterm).
Actually, the port behaves properly, while I saw earlier today that the version installed using "pkg install xterm" did not. (I would have assumed that the pkg used the same makefile, etc). I can see this by compiling (but not installing) the port, and running the executable from the work-directory. Running with "script", I can see that Emacs doesn't send any explicit escapes to set the title. That's done by (rather old) code to use the command-line to set X resources. Revisiting the case which showed a problem (xterm -e emacs -nw foo), that no longer gives me an xterm which lacks a title when iconified. Now it shows "emacs". Nothing in my home directory (such as WMState) has changed since that point; this is a wmaker session which I started shortly before checking xterm with emacs.
(In reply to Thomas E. Dickey from comment #6) I build everything via ports (except compilers). But that shouldn't make a difference from pkg since the FreeBSD pkg's are build on a 12.0-RELEASE with default buildoptions set. Makefiles of ports and pkg's are the same. The "-nw" option doesn't have any effect here on the miniwindow titlebar. I did build Emacs without X11 though (emacs-nox "flavor" in FreeBSD terms). I'll try to build regular emacs and running it in an Xterm to see what happens.
Seems that I can only start Emacs without X11 when the emacs-nox flavor is installed.
Found out that in Midnight Commander the problem can be circumvented by setting "Xterm window title" in the settings (menu F9 > Options > Layout). In that case the window title changes to "mc[user@hostname]:~/current/directory", and the miniwindow icon has a title again.
I don't use emacs, but recall that in some systems the no-X version can be the same executable as the X version. On Friday I had installed emacs-nox, and possibly got confused due to fatigue. Revisiting it today, I installed the emacs package (replacing the emacs-nox package). By default, that runs in X. But unsetting $DISPLAY, it runs in xterm. Given that, it appears as on Friday (showing "xterm" as the title of the miniwindow). Since emacs does not alter the title, it seems that the title would come from xterm or other configuration (such as window manager). But revisiting the screenshot: xterm's icon is different from that on my system (so I assume you have some window-manager theme in effect). However, the icon for each xterm should be the same unless it is specially configured. The screenshot shows the same icon for the htop and top miniwindows, but different ones for mc and emacs. The mc options menu selection you mentioned tells mc to use an escape sequence to set the title string. That, and emacs behavior indicate that the problem is in the behavior when no escape sequence is used. Before installing the xterm port, I did save the packaged xterm as "xterm-347", but that does not produce a miniwindow without a title, whether from emacs or mc. Whether from the (renamed) package, the port, or my self-build, xterm is showing me the instance name in the title of the miniwindow. That's expected, but earlier on Friday I did see a blank title which I'm not able to repeat.
Regarding instance name and title ("application name" and "instance name" are the same in the manual page: https://invisible-island.net/xterm/manpage/xterm.html#X-Toolkit-Options:-title
Continuing, I noticed an anomaly which might be related: in vile, I ran an external "ls" command and before returning to full-screen mode, iconified the xterm. The resulting miniwindow had no title (although the xterm did have the application in the title area).
I've made a fix which will be in #351
(In reply to Thomas E. Dickey from comment #13) Great thanks! I'll report when it lands in the ports. Regards, Marco
A commit references this bug: Author: ehaupt Date: Mon Nov 18 09:19:55 UTC 2019 New revision: 517861 URL: https://svnweb.freebsd.org/changeset/ports/517861 Log: - Update to 351 - This update fixes a bug during deciding when to fallback from UTF-8 decoding to ISO-8859-1 decoding PR: 241961 (based on) Submitted by: mbeis@xs4all.nl MFH: 2019Q4 Changes: head/x11/xterm/Makefile head/x11/xterm/distinfo
I've just updated the port. I am going to keep the PR open for further feedback.
Problem solved. All is working well again. Thanks! Marco
A commit references this bug: Author: ehaupt Date: Mon Nov 18 14:59:04 UTC 2019 New revision: 517871 URL: https://svnweb.freebsd.org/changeset/ports/517871 Log: MFH: r517861 - Update to 351 - This update fixes a bug during deciding when to fallback from UTF-8 decoding to ISO-8859-1 decoding PR: 241961 (based on) Submitted by: mbeis@xs4all.nl Approved by: ports-secteam (joneum) Changes: branches/2019Q4/x11/xterm/Makefile branches/2019Q4/x11/xterm/distinfo