Consider moving from ncurses to libtickit

[lenormf]

According to @leonerd, libtickit would provide a superset of ncurses, with the added bonus of True Color support if asked for nicely.

The pros are that we get rid of an old library whose API isn't the best.

The cons are migrating to a new library might introduce more bugs, or maybe lead to cases where something implemented with ncurses isn't as easily done with the new lib.

Discuss.

[occivink]

Would it also be possible to differentiate mappings like <tab> and <c-i> with this library? And map function keys?

[mawww]

I think if we ever get rid of ncurses, its probably going to be for a direct terminal output, just using terminfo.

libtickit is not a common enough library so that I'd feel comfortable adding it as a dependency.

The way we do the output in ncurses is already not relying on much more than filling the ncurses screen and blitting that. Ncurses does some fancy things behind to optimize the redraw commands, but the biggest one should be pretty easy to implement ourselves as we already have a diff implementation.

For the input part, we already parse some CSI ourselves for FocusIn/FocusOut, and we could extend that to support libtickit proposed input format, but it looks like most terminals dont emit that anyway.

Regarding 24bit support, I dont think we actually need it, we never have more than 256 colors at once on the screen, we'd better use the palette changing, which is already implemented, and is much more performant. What we need is palette reset (OSC 104) support in the terminal emulators that dont support it yet (rxvt-unicode comes to mind), and palette change support as well (tmux does not).

In general, I think we are fine with ncurses for the most part. The only real pain point is input handling, but we wont get any gains until terminal emulators start supporting unambiguous key representation.

[lenormf]

How would input handling be better using libtickit ? Complaints regarding the default alt/ctrl binding are recurrent, and apparently the lib provides tools to alleviate some of those issues (?).

As for TC support, I'd say most tools that implement it won't bother with palette switching as the latter is mostly considered a workaround, which is why e.g. the maintainer of tmux cba to implement it (he does accept PRs though). In the end, as time goes by, more and more tools will only support TC, and compatibility with other tools that sticked with palette-switching such as Kakoune will be an ever widening gap. If it's not too much work to implement and it's really more efficient, we might as well make 24bit colors an opt-in feature (probably not a good idea but eh).

[leonerd]

FYI, the main libtickit manpages are currently found at http://www.leonerd.org.uk/code/libtickit/doc/

@occivink - technically libtickit (via its internal dependency libtermkey) can distinguish a Ctrl-I from a Tab, though most terminals don't send distinct byte sequences for them. A few can, but that tends not to be enabled by default. Part of the reason for declaring libtermkey end-of-life and moving it into libtickit entirely, is so that the output part of the driver can enable that mode, and so more terminals should make it distinct.

[mawww]

No plans to switch any time soon, closing for now.