[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Update Alacritty terminfo
From: |
Christian Dürr |
Subject: |
Re: [PATCH] Update Alacritty terminfo |
Date: |
Wed, 15 Jan 2020 20:54:10 +0100 |
User-agent: |
Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 |
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.
> 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.
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