[slang-users] Treat screen* and tmux* as almost_vtxxx

[Yuri Khan <yuri.v.khan@xxxxxxxxx>]

Hello,

I stumbled on a bug, and it seems to stem from S-Lang.

The actual problem I see involves Midnight Commander, tmux or GNU
Screen, and 256-color configuration.

* Start xterm or any other X terminal emulator capable of displaying
  256 colors.

      (xterm)$ echo $TERM
      xterm-256color

* Configure tmux to support 256 colors and start it:

      (xterm)$ echo 'set -g default-terminal "tmux-256color"' \
               > .tmux256.conf
      (xterm)$ tmux -f .tmux256.conf
      (tmux)$ echo $TERM
      tmux-256color

  (Alternatively, the "screen-256color" value also enables 256 colors
  in tmux. The difference is that "tmux-256color" also enables italics
  support.)

* Start Midnight Commander:

      (tmux)$ mc

* Switch to the subshell by pressing Ctrl+O.

* Enter some command that will produce some visible output.

      (mc)$ ls -al

* Now resize the terminal emulator window or split the tmux window into
  panes. (The problem is triggered by any change of the number of lines
  or columns in the pane in which mc is running.)

Expected behavior: the output of `ls -al` remains on screen.

Observed behavior: the output disappears.


The function `SLtt_initialize` matches the $TERM variable against
several known strings which cause the `almost_vtxxx` variable to be set.
The tests include prefix match checks for "linux*", "con*", "xterm*",
"rxvt*", "Eterm*" and "vt[1-9]*" with an exception for "vt52", and an
exact match check for "screen".

This `almost_vtxxx` variable then affects two things: causes fallback
initialization if the terminfo file designated by $TERM cannot be loaded,
and prevents the `SLtt_Force_Keypad_Init` variable from being set to 1.
(That is, with TERM=screen, SLtt_Force_Keypad_Init remains at -1, while
with TERM=screen-256color, TERM=tmux, or TERM=tmux-256color,
SLtt_Force_Keypad_Init gets set to 1.) This in turn leads to
`SLtt_init_keypad` and `SLtt_deinit_keypad` sending the `smkx` and
`rmkx` sequences to the terminal.

I honestly do not know how or why keypad initialization affects the
disappearance of output on pane resize. But it does. The problem goes
away if I change the "screen" exact match to a prefix match and add a
similar check for "tmux*", or if I stick a `return;` at the top of
`SLtt_init_keypad`.

The problem also manifests with GNU Screen in place of tmux if its
`altscreen` option is set to `on`. Conversely, setting the
`alternate-screen` option to `off` in tmux makes the output no longer
disappear. However, alternate screen is indispensable for mc, as without
it `mc` does not preserve subshell output when panels are toggled on and
back off, which is about as severe a loss in usability as the original
clear-on-resize problem.

Allow me to propose the following small patch, prepared against current
`master` (23102fc). Alternatively, I can patch `mc` to reset
`SLtt_Force_Keypad_Init` back to -1 immediately after the call to
`SLtt_initialize`, but I think this patch is cleaner.


From 7bc9835b787e3aee4472d38c5b26d58a76fa65b5 Mon Sep 17 00:00:00 2001
From: Yuri Khan <yurivkhan@xxxxxxxxx>
Date: Sun, 1 May 2016 01:11:02 +0600
Subject: [PATCH] Treat screen* and tmux* as almost_vtxxx

---
 src/sldisply.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/sldisply.c b/src/sldisply.c
index a679102..f7a10d8 100644
--- a/src/sldisply.c
+++ b/src/sldisply.c
@@ -2729,7 +2729,8 @@ int SLtt_initialize (SLFUTURE_CONST char *term)
    almost_vtxxx = (Vt100_Like
            || Linux_Console
            || is_xterm
-           || !strcmp (term, "screen"));
+           || !strncmp (term, "screen", 6)
+           || !strncmp (term, "tmux", 4));

 # ifndef USE_TERMCAP
    if (Terminfo != NULL)
-- 
2.8.1
_______________________________________________
For list information, visit <http://jedsoft.org/slang/mailinglists.html>.