bug-ncurses
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]