Re: [PATCH] Update Alacritty terminfo

[Thomas Dickey]

On Wed, Jan 15, 2020 at 08:54:10PM +0100, Christian Dürr wrote:
> On Wed, Jan 15, 2020, at 10:33, Thomas Dickey wrote:
> > On Tue, Jan 14, 2020 at 10:08:02PM +0100, Christian Dürr wrote:
> > > 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.
> >
> > The mouse issue (XM/xm) was addressed here:
> >
> > 20181124
> >     + modify the initialization checks for mouse so that the xterm+sm+1006
> >       block will work with terminal descriptions not mentioning xterm
> >       (report by Tomas Janousek).
> >
> > which (since this is patching current ncurses) is not relevant anymore.
> 
> Oh, since Archlinux uses 6.1, that patch wasn't yet applied on my ncurses.
> However after testing with Gentoo, I can confirm that it's not an issue 
> anymore.
> 
> However to make this work with Alacritty, the changes still need to be applied
> to move xterm+sm+1006 in front of xterm-basic. So once that's done, everything
> should be good to go as far as I know.

yes (to make kmous consistent with XM/xm)

> > I made a to-do note to expand TS/XM/xm in user_caps(5), e.g.,
> >
> >     https://invisible-island.net/ncurses/man/user_caps.5.html
> 
> I'd assume that this means that the `xm` which comes with `xterm+sm+1006` is
> correct for SGR mode, even though it sends p1 and p2 first, which are x and y
> coordinates according to the comment in misc/terminfo.src? Usually I'd expect
> the first parameter in SGR mode to be the encoded button value.

hmm - errors in xm may be present, since nothing checks it:

# The xterm mouse protocol is used by other terminal emulators.
# In this section, two extended capabilities are used to illustrate the mouse
# protocol: XM and xm.  The "XM" capability is recognized by ncurses to allow
# enabling/disabling other mouse protocols.  The "xm" capability describes the
# mouse response; currently there is no interpreter which would use this
# information to make the mouse support completely data-driven.

...but XM is used (and ultimately, checked)
 
> However if you plan to explain this more in the user_caps manpage, I'm looking
> forward to just reading up on that there.
> 
> Kind regards,
> 
> Christian Duerr

-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature