win: tui: libtermkey fork

[justinmk]

We are currently using @equalsraf fork of libtermkey. Limitations:

• The termkey_waitkey() function is not implemented in windows, since there is no poll() alternative.

#3902 (comment)

#6315 (comment)

cc @leonerd: Would be nice to merge @equalsraf changes to libtermkey upstream. The fork is this commit.

[leonerd]

Hrm. Mixed reaction.

I'm happy enough to make the termios stuff conditional - though personally I'd do it with

#ifdef HAVE_TERMIOS

and then conditionally set that based on not being _WIN32

A lack of termkey_waitkey is fair enough - the user will just have to provide that part by their own means. Though again I'd consider making it conditional on some actual symbol like HAVE_POLL. Also don't forget to elide it from the .h file there.

I'm not sure what's with all the newly added files; they seem to relate to cmake. Is that part of the same change? Can that not be split into a different thing somehow?

[justinmk]

@leonerd Yes the cmake stuff could be split. Though we would need somewhere, so we would probably still need to maintain a fork.

[leonerd]

You already maintain all the cmake stuff for nvim anyway though, so maybe that's not so bad?
I just don't feel confident in shipping/maintaining a cmake config when I know nothing about the system.

[justinmk]

Sure, if we can move the cmake stuff to neovim then we will do that. @equalsraf then IIUC we wouldn't need to download the appveyor artifact, instead we would build it?

[equalsraf]

Understood, I'm splitting things up then, here is the relevant commit equalsraf/libtermkey@578fe18

@leonerd I've added HAVE_TERMIOS like you suggested.

How should I ellide termkey_waitkey from termkey.h.in based on a compile time HAVE_POLL?

Full branch and appveyor builds at equalsraf/libtermkey#1