Re: Mismatch with st terminfo files

[Sebastian J. Bronner]

Hi Thomas,

thanks for your input so far.

> > Using st 0.8.2 with TERM=st-256color and the terminfo database from
> > ncurses 6.1, I get problems with two applications in tmux:
> >
> > * neovim: tmux crashes on nvim start
> > * w3m: keypresses aren't registered

I can confirm that starting with the ncurses terminfo database from
2019-06-09 and all later versions the tmux crash is gone. The relevant
change was the addition of Ms=....

> > When using the terminfo file supplied with st [1], all is well: vim causes
> > no crashes, and w3m gets its keystrokes.
> 
> That's interesting, since st provides a corrupt file :-)

I have submitted a patch to st that fixes the bad Se and Ss
capabilities, which has been accepted and applied in git:

https://git.suckless.org/st/commit/83866428de031300eab03fbb116bcf7d2b1d4f60.html

> Essentially the problem was that they added capabilities which are
> supposed to have values, I made one fix but overlooked another.
> (The tic/infocmp programs didn't handle the case well when st's
> terminal entry said a value was a boolean and another entry said it was
> a string).
> 
> The most recent terminal database at the webpage fixes that (by
> eliminating the defects from st' terminfo file)
> 
> https://invisible-island.net/ncurses/ncurses.html#download_database
> 
> (subsequent database updates aren't _there_ since they won't work
> with the vanilla ncurses 6.1 - long story).

There are further differences between the current ncurses and the
current st upstream terminfo entries for st and st-256color, which may
warrant further patches against st upstream. However, in order to submit
patches, I would like to understand the differences better. Would you
give me feedback on the diff-formatted list below?

--- st.st-0.8.2+20+g8386642     2019-11-06 16:25:44.951353958 +0100
+++ st.ncurses-20191102 2019-11-06 16:27:00.506141009 +0100
 st| simpleterm,
+       ccc,
+       
initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
+       oc=\E]104\007,
# These seem to be meant for st-256color. That is where the developers
# of st put them, anyway. However, they are placed here, in st, and
# st-256color has these explicitly removed.
#
-       Tc,
# What is this? I see that it was intentionally removed in the
# 2018-01-04 release.
#
+       XT,
# tic states that XT is expected with kmous. But with XT tic talks about
# two other unmet expectations: 'Expected orig_colors capability with XT
# to have 39/49 parameters' and '"tsl" capability is redundant, given
# XT'.  However, orig_colors does not seem to have the expected
# parameters, and if tsl is removed, the titlebar does not get updated.
# This leaves me thinking that XT might specify more than st really
# supports.
#
+       dsl=\E]0;\007,
+       TS=\E]0;,
# These are pulled in from xterm+sl. Can the titlebar "status line" even
# be disabled (tsl)? TS is supposed to be a replacement for tsl when no
# parameter is needed, which seems to be exactly what is needed with st.
# But using it without tsl results in the titlebar not being updated. My
# guess is that st can't do this.
#
-       flash=\E[?5h$<80/>\E[?5l,
+       flash=\E[?5h$<100/>\E[?5l,
# Upstream says 80 columns, here 100 are specified. Is something wrong
# with 80?
#
-       kcbt=\E[Z,
-       kent=\EOM,
# I don't understand their function from reading terminfo(5). What are
# they for?
#
+       rin=\E[%p1%dT,
# According to docs, st does not support scrolling. Can this capability
# be right, then? It is pulled in from ecma+index.
#
-       
sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
+       
sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p7%t;8%;m,
# Am I assuming correctly that this change fixes tic's complaints
# 'checking sgr(dim) "\e(B\e[0m"; compare to "\e[2m"; unmatched "2m"'
# and "enter_dim_mode differs from sgr(5)"?
#
+       u6=\E[%i%d;%dR,
+       u7=\E[6n,
+       u8=\E[?1;2c,
+       u9=\E[c,
# What are these?
#
+       kDN3=\E[1;3B,
+       kDN5=\E[1;5B,
+       kLFT3=\E[1;3D,
+       kLFT5=\E[1;5D,
+       kNXT3=\E[6;3~,
+       kNXT5=\E[6;5~,
+       kPRV3=\E[5;3~,
+       kPRV5=\E[5;5~,
+       kRIT3=\E[1;3C,
+       kRIT5=\E[1;5C,
+       kUP3=\E[1;3A,
+       kUP5=\E[1;5A,
# And these?
#
 st-256color| simpleterm with 256 colors,
-       ccc,
+       ccc@,
-       
initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
+       initc@,
-       oc=\E]104\007,
+       oc@,
# These seem to be intended for use here. However, they are being
# removed. What am I missing?
#
-       pairs#0x7fff,
+       pairs#0x10000,
# This might cause attempted access to uninitialized memory, no?
#
-       
setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
-       
setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
# Why removed?
#

> > I was wondering: What speaks against allowing the various packagers of
> > st (debian stterm) to provide the current terminfo files as part of
> 
> That would be a bad idea, since st's developers haven't fixed their
> terminfo bug (more than two years).  If you do that, there's no point
> in discussing the results on this list.

My suggestion was backwards, I apologize. I have since realized that a
central database of terminfo entries is vital for remote sessions. If
each terminal package were to provide its own terminfo entries, you
would have to install every terminal you expected users to use when
connecting to a machine via ssh.

I appreciate your explanation, despite being faced with this exact bad
idea in the past, as I have since discovered.

Sincerely,
Sebastian