Bug 282647 - termcap entries for tmux missing title setting capabilities (also for xterm?)
Summary: termcap entries for tmux missing title setting capabilities (also for xterm?)
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 14.1-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-09 12:56 UTC by Duane
Modified: 2024-12-05 10:55 UTC (History)
4 users (show)

See Also:


Attachments
fix termcap, v0 (6.22 KB, patch)
2024-11-22 18:22 UTC, Jan Beich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Duane 2024-11-09 12:56:16 UTC
Entries:

    :ts=\E]2;:fs=^G:

(as seen in `xterm-termite`) should be added to the `tmux` and `tmux-256color` entries in `/usr/share/misc/termap` to allow the window (pane) title to be set in tmux (I think available since v2.3).

These should probably also be added to the basic `xterm` entries but I'm not sure if there is any compatibility issue this could raise.  Interestingly it appears some programs override these `xterm` capabilities to add them manually themselves anyway if they are missing (notably `vim` and `tmux` definitely do this).
Comment 1 Duane 2024-11-09 13:46:57 UTC
Further investigation suggests that the following entries:

    :ti=\E[?1049h\E[22;0;0t:te=\E[?1049l\E[23;0;0t:

should also be added to allow the title to revert to the previous value when an application closes (most notably clearing the "Thanks for flying VIM" message).
Comment 2 Jan Beich freebsd_committer freebsd_triage 2024-11-21 23:18:13 UTC
(In reply to Duane from comment #1)
ti/te were moved from xterm to xterm-clear due to POLA in base 9190ba057c57. tmux in termcap does have ti/te but the behavior is controlled by alternate-screen option (similar to altscreen in screen program).

Alternatively, on FreeBSD >= 14 simply install misc/terminfo-db to get more terminal entries (e.g., tmux-direct for 24-bit colors) and Linux-style defaults (e.g., ti/te in xterm).
Comment 3 Duane 2024-11-22 03:16:24 UTC
That change seems like a backwards decision.  Instead of configuring the program to not clear the screen when it exits, we lie about whether the terminal is capable of clearing the screen?  If using `less` you just add the `-X` option.

We now have the bizarre situation where `vim` for example seems to use its internal terminal definitions if the terminal is listed as `xterm` because it can no longer trust the provided termcap files as being complete.  It actually does the clear if the TERM is exactly 'xterm', but not for derivative or other values.

It leads to a weird circumstance where I get more reliable behaviour from programs if I set the terminal to `xterm` regardless of what it really is because then programs use their more complete capabilities themselves.  This is how I actually discovered that these entries were missing from the FreeBSD termcap files.

Additionally, neither of the additional entries in terminfo-db contain the ts or fs capabilities so this doesn't solve that issue.
Comment 4 Jan Beich freebsd_committer freebsd_triage 2024-11-22 16:29:24 UTC
(In reply to Duane from comment #0)
> :ts=\E]2;:fs=^G:

tmux uses :ts=\E]0;:fs=^G: per https://github.com/tmux/tmux/commit/295ace682020 which matches xterm+sl per https://github.com/mirror/ncurses/blob/v6.4/misc/terminfo.src#L5709
FreeBSD homegrown termcap mostly follows terminfo except for POLA or features that cannot be translated to termcap. So, this should be easy to fix but I don't use termcap myself anymore.

(In reply to Duane from comment #3)
> Additionally, neither of the additional entries in terminfo-db contain the ts or fs capabilities so this doesn't solve that issue.

terminfo for tmux has use=xterm+sl but somehow base ncurses picks up termcap unless an entry is only defined in terminfo e.g.,

$ pkg install terminfo-db
$ tmux set -g default-terminal tmux-direct
$ tmux respawn-pane -k
$ (tput ts; echo) | vis -o
\033]0;
$ (tput fs; echo) | vis -b
^G

CC @bapt per base b75fb12b6827 which suggested termcap to be used only as fallback.
Comment 5 Jan Beich freebsd_committer freebsd_triage 2024-11-22 18:22:58 UTC
Created attachment 255394 [details]
fix termcap, v0
Comment 6 Duane 2024-11-22 22:09:11 UTC
(In reply to Jan Beich from comment #4)

You are looking at the codes it transmits, not the codes that it receives.  This is an example of application having default xterm behaviour if the xterm termcap/terminfo is missing or broken.  The correct section of code is https://github.com/tmux/tmux/blob/ceaf9b7452983423b679b25d905ce6750a0e299a/input.c#L2401-L2434

Here it accepts either 0 or 2 to change the title, but cross-referencing with https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Operating-System-Commands shows that the difference between them is that 0 can also change the icon name as well as the title.

The absence of any handling for OSC 1 (just changing the icon name) suggests that the correct thing to declare to set just the title would be OSC 2.  Using OSC 0 in the capability may imply that the icon name is settable.
Comment 7 Jan Beich freebsd_committer freebsd_triage 2024-11-23 06:45:55 UTC
(In reply to Duane from comment #6)
If OSC 0 is incorrect for tmux then terminfo should probably use=xterm+sl-twm (instead of use=xterm+sl). CC upstream maintainer.
Comment 8 Thomas E. Dickey 2024-11-23 23:17:41 UTC
tmux uses "0" intentionally:

commit d4ce210713cc907fc69497c51cf9b64d2f414ca4
Author: Nicholas Marriott <nicholas.marriott@gmail.com>
Date:   Mon Jul 20 10:34:11 2015 +0000

    Correct the tsl/fsl sequence to ]0 not ]2 (from Marcel Korpel). While
    here, Xr xterm and remove some advice about elinks that is better
    elsewhere.