Bug 241961 - x11/xterm: after update to 350, disappearing miniwindows titles in WindowMaker
Summary: x11/xterm: after update to 350, disappearing miniwindows titles in WindowMaker
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Emanuel Haupt
Depends on:
Reported: 2019-11-14 09:26 UTC by Marco Beishuizen
Modified: 2019-11-18 14:59 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (ehaupt)

screenshot (514.24 KB, image/png)
2019-11-15 10:06 UTC, Marco Beishuizen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Beishuizen 2019-11-14 09:26:39 UTC
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.
Comment 1 Thomas E. Dickey 2019-11-14 20:44:06 UTC
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).
Comment 2 Marco Beishuizen 2019-11-15 08:37:46 UTC
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.
Comment 3 Thomas E. Dickey 2019-11-15 09:09:59 UTC
A screenshot would help (I don't know what "miniwindow" might be, related to xterm).
Comment 4 Marco Beishuizen 2019-11-15 10:06:41 UTC
Created attachment 209162 [details]

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.
Comment 5 Thomas E. Dickey 2019-11-15 23:28:11 UTC
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).
Comment 6 Thomas E. Dickey 2019-11-16 01:40:29 UTC
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.
Comment 7 Marco Beishuizen 2019-11-16 13:24:58 UTC
(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.
Comment 8 Marco Beishuizen 2019-11-16 14:39:47 UTC
Seems that I can only start Emacs without X11 when the emacs-nox flavor is installed.
Comment 9 Marco Beishuizen 2019-11-16 14:55:18 UTC
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.
Comment 10 Thomas E. Dickey 2019-11-17 19:43:39 UTC
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

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.
Comment 11 Thomas E. Dickey 2019-11-17 19:53:25 UTC
Regarding instance name and title ("application name" and "instance name"
are the same in the manual page:

Comment 12 Thomas E. Dickey 2019-11-17 20:02:20 UTC
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).
Comment 13 Thomas E. Dickey 2019-11-17 22:41:12 UTC
I've made a fix which will be in #351
Comment 14 Marco Beishuizen 2019-11-18 07:55:10 UTC
(In reply to Thomas E. Dickey from comment #13)
Great thanks!
I'll report when it lands in the ports.

Comment 15 commit-hook freebsd_committer 2019-11-18 09:20:02 UTC
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

  - 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

Comment 16 Emanuel Haupt freebsd_committer 2019-11-18 09:26:52 UTC
I've just updated the port. I am going to keep the PR open for further feedback.
Comment 17 Marco Beishuizen 2019-11-18 13:34:04 UTC
Problem solved. All is working well again.

Comment 18 commit-hook freebsd_committer 2019-11-18 14:59:28 UTC
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

  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)