Re: [PATCH] Update Alacritty terminfo

[Christian Dürr]

On Tue, Jan 14, 2020, at 10:31, Thomas Dickey wrote:
> On Mon, Jan 13, 2020 at 08:50:22PM +0100, Christian Dürr wrote:
> > On Sun, Jan 12, 2020, at 12:38, Thomas Dickey wrote:
> > > On Tue, Dec 31, 2019 at 05:00:04PM +0100, Christian Dürr wrote:
> > > > This updates the Alacritty terminfo to the latest revision available in 
> > > > its
> > > > repository.
> > >
> > > I've been busy, but took a quick look last night.
> > >
> > > Offhand (I haven't investigated the key-modifiers),
> > > the only change needed appears to be the overlooked "ech" feature.
> >
> > I'd assume by this you mean that the `ech` feature should be removed, since
> > Alacritty does not support it?
>
> no - the reverse.  In my comments before the entry, I had observed in
> the older version that ech didn't work properly, and later it did.
> In the entry I had left it cancelled, e.g.,
>
>       ech@,
>
> Removing that restores the feature (in changes for this week).

Oh, that explains a lot of misunderstandings I've had with your original email,
thanks for clearing that up.

The original cause behind this patch was actually a report that mouse
interactions weren't working in `htop`, which obviously isn't explained by the
`ech` capability. However I took the opportunity to look into this myself and it
seems like there are some interesting differences in the user-defined
capabilities.

Just for reference, here's the output of `infocmp -xd` of the terminfo I've sent
in the original patch versus the latest ncurses version:

```
comparing alacritty-ncurses to alacritty.
    comparing booleans.
    comparing numbers.
        pairs: 65536, 32767.
    comparing strings.
        ech: NULL, '\E[%p1%dX'.
        TS: '\E]2;', NULL.
        XM: '\E[?1006;1000%?%p1%{1}%=%th%el%;', NULL.
        xm: '\E[<%p1%d;%p2%d;%p3%d;%?%p4%tM%em%;', NULL.
```

I believe almost all these differences could lead to some problems, but just
fixing these specific entries should be pretty trivial with the existing ncurses
entry and I don't think there's any need to make any big changes like just
pasting the entire terminfo into ncurses without any deduplication.

>       pairs: 65536, 32767.

The color pair difference should be irrelevant, since this is only a problem on
macOS (see https://github.com/alacritty/alacritty/issues/1862). So I think
`htop` on Linux should work with 65536 colors.

>       XM: '\E[?1006;1000%?%p1%{1}%=%th%el%;', NULL.

This is the cause of Alacritty's mouse mode not working in htop. As it turns
out, the order of xterm imports is problematic. Since `xterm+sm+1006` comes
after `xterm+app`, the `XM` attribute is set. However the `kmous` is overwritten
by `xterm+app` to `\e[M`, breaking `htop` mouse mode.

In an `xterm-*` terminfo this could be fixed by reordering the imports, however
when done in just the `alacritty` terminfo, `htop` does not work properly.  I'd
assume they're doing some direct `$TERM` checking.

Since `xm` doesn't seem to be used and it's incorrect for SGR mouse mode
anyways, I think it should be fine to just remove the `xterm+sm+1006` import to
fix this.

>       TS: '\E]2;', NULL.

I'm not sure about `TS`, since I'm not entirely familiar with where it is used,
but so far I haven't seen it cause any issues so it should be fine.

To cut a long story short, I think the following diff are the changes I'd
suggest to fix `htop` not working with Alacritty:

```
 diff --git a/misc/terminfo.src b/misc/terminfo.src
index 4f45020c..a9c9563b 100644
--- a/misc/terminfo.src
+++ b/misc/terminfo.src
@@ -6930,7 +6930,7 @@ terminology|EFL-based terminal emulator,
 # The program sources include "alacritty" and "alacritty-direct", which are
 # copied from "xterm-256color" and "xterm-direct" (but using semicolon for
 # subparameter delimiter).  Refactored here to use ncurses building blocks -TD
-alacritty|alacritty terminal emulator,
+alacritty-ncurses|alacritty terminal emulator,
        rs1=\Ec\E]104\007, use=xterm+256color,
        use=alacritty+common,

@@ -6944,9 +6944,9 @@ alacritty+common|base fragment for alacritty,
        npc,
        ech@, kb2=\EOE, kbs=^?, kcbt=\E[Z, kent=\EOM, Se=\E[0 q,
        use=ecma+index, use=xterm-basic, use=xterm+app,
-       use=ansi+rep, use=xterm+sm+1006, use=xterm+tmux,
-       use=ecma+strikeout, use=xterm+sl-twm, use=ecma+italics,
-       use=xterm+pce2, use=xterm+pcc2, use=xterm+pcf2,
+       use=ansi+rep, use=xterm+tmux, use=ecma+strikeout,
+    use=xterm+sl-twm, use=ecma+italics, use=xterm+pce2,
+    use=xterm+pcc2, use=xterm+pcf2,

 #### Kitty
 # https://github.com/kovidgoyal/kitty
 ```

> On Sunday I investigated the modified-keys, and updated the comment.

Thanks!

> > I've checked `vttest` and it performed exactly as XTerm, with the small
> > exception that the window is not automatically resized. The lack of 
> > automatic
> > resizing can lead to issue swith `vttest` though, which means `Delete
> > Characters` suddenly looks like `ABAAAAAAAA...` instead of `AB`, since the
> > characters "outside" the expected window size aren't removed.
> >
> > Since it resizes half way through the test, that makes it quite difficult to
> > verify though. I had to run the test twice, making sure the window had the 
> > exact
> > right size for each part of the test before starting either of them.
> >
> > I'd assume that it's not a requirement for `vttest` to be able to resize the
> > window by itself, right? Since Alacritty's results are identical with 
> > Termite
> > when the awkward resizing is ignored and it's just all run at big terminal
> > widths.
>
> no, it's a common problem.  I use this script for those terminals,
> so I can make useful comparisons:
>
> #!/bin/sh
> # $Id: run-vttest,v 1.2 2019/11/15 22:53:01 tom Exp $
> # use this wrapper for terminals that do not resize via escape sequences
> ROWS=$(stty size| awk '{print $1;}')
> COLS=$(stty size| awk '{print $2;}')
> vttest "$@" ${ROWS}x${COLS}.${COLS}

This is actually extremely helpful, thanks for sharing. This makes working with
vttest a lot easier for those terminals that do not support the escape for
dynamic resizing.

Thanks for all your help with getting this figured out.

Kind regards,

Christian Duerr