Hardcode Windows Terminal control sequences

[dankamongmen]

Now that #2009 is complete, we're no longer failing in the setupterm() call on Windows. We're also entirely without control sequence data. Using the handy guide at https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences, hardcode these in a Windows-only variant of interrogate_terminfo(). I think we'll then work on Windows, in some capacity.

[WSLUser]

Would this be basically creating your own terminfo for Windows and is there any way to adopt the existing one and simply update it based on the list provided in the doc?

[dankamongmen]

i mean, is there an official one? i'm unable to get setupterm() to run successfully, but given that it does exist as a linkable function, i'd think something's there...

[WSLUser]

https://invisible-island.net/ncurses/terminfo.src.html#tic-ms-terminal

See also microsoft/terminal#8303, as noted, there's no TERM env var available but other terminals are able to use their terminfo so there must be some way for notcurses to use that terminfo entry and update it though maybe it might just be better to create a new one based on what already exists.

[WSLUser]

You could also just treat Windows Terminal as what it reports itself to be: xterm-256color

[dankamongmen]

https://invisible-island.net/ncurses/terminfo.src.html#tic-ms-terminal

oh agreed that there's a terminfo definition, just not a database. you need the defintiion because what if i'm using Microsoft Terminal and ssh into a linux machine. that linux machine needs a correct terminfo definition for windows terminal.

but i'm not seeing a bunch of terminfo database entries on a windows machine, and @magiblot stated over in #463 that it's really not a thing there, that there is generally just the one terminal on windows.

[dankamongmen]

however, this terminfo definition will be useful to me, as it tells me exactly what to hardcode =].

[dankamongmen]

looks like we also need to roll our own tputs().

[dankamongmen]

i don't know what happened to the windows build, but it's completely failing on stupid shit, and even master's builds have been broken since yesterday due to some rust, and it's all very depressing and i don't want to work on this anymore right now. i'll come back to it in a few days. i hope master is building again by then. i can't stand all this red.

[magiblot]

@magiblot stated over in #463 that it's really not a thing there

The finest example of this is, as @WSLUser noted, that the TERM variable is not set by default when opening a classic console, which is likely the most used terminal environment on Windows.

This doesn't mean terminfo isn't useful at all, but rather that you can live without it. Which path is easier to take depends on your application. When I tried to solve this problem in Turbo Vision I had no dependency on terminfo, so I just ignored it and went the Win32-Console-API way:

• Use SetConsoleMode to detect whether ENABLE_VIRTUAL_TERMINAL_PROCESSING is supported; if it isn't (pre-W10), draw using only Win32 Console API calls (SetConsoleTextAttribute, SetConsoleCursorPosition...)
• Get input events via ReadConsoleInputW (which, unlike control sequences, reports window resize events and full modifiers for key and mouse events).
• Allocate a console window (AllocConsole) when console operations fail on standard handles (usually because they are being redirected or they are regular pipes instead of a Win32 console).

If you can't get rid of terminfo because you need to reason about terminal capabilities, you could try assuming TERM=xterm-256color when no TERM is provided and keep on doing console I/O through stdio. My guess is that terminfo support would additionally allow you to run natively on non-Win32-Console-based terminals such as mintty.

[WSLUser]

Mintty actually has it's own terminfo database (due to some private sequences it uses) though you can use xterm-256color as well and will work reasonably well.

[WSLUser]

however, this terminfo definition will be useful to me, as it tells me exactly what to hardcode =].

That definition is outdated so be sure you use the doc as the primary source.

[dankamongmen]

• Allocate a console window (AllocConsole) when console operations fail on standard handles (usually because they are being redirected or they are regular pipes instead of a Win32 console).

Hrmmm, this doesn't make sense to me. If I'm redirected to a file, why would I want to pop up a console window? I'd just emit my output into that file, like I do everywhere else.

If you can't get rid of terminfo because you need to reason about terminal capabilities, you could try assuming TERM=xterm-256color when no TERM is provided and keep on doing console I/O through stdio. My guess is that terminfo support would additionally allow you to run natively on non-Win32-Console-based terminals such as mintty.

Well, I realized that I want to keep terminfo to keep using tiparm() and friends, not wanting to rewrite all of that code. I just elide the call to setupterm() and del_curterm() at initialization and shutdown, and load the escapes by hand. So I'll still be using terminfo. Something I was wondering, though: what's the story when someone ssh's into a Windows machine? Is OpenSSHd generally built in an e.g. cygwin environment, that will have a full terminfo database? What about other, native sshds?

[dankamongmen]

That definition is outdated so be sure you use the doc as the primary source.

yeah, noticed that, am doing so. i expect this to be done tonight, but last night i was running into strange and seemingly sudden build failures on windows, so who knows. admittedly, i'd been up for about 48 hours, so who knows whether any of it was real.

[magiblot]

If I'm redirected to a file, why would I want to pop up a console window? I'd just emit my output into that file, like I do everywhere else.

Exactly. I was not suggesting that you should do it that way, it was just an example of an application embracing the Win32 Console API instead of using terminfo.

[dankamongmen]

Exactly. I was not suggesting that you should do it that way, it was just an example of an application embracing the Win32 Console API instead of using terminfo.

grokked, thanks for the clarification

[dankamongmen]

I've loaded the most important escapes into src/lib/windows.c on the dankamongmen/fauxmemstream branch, and we now have color etc. in Windows Terminal. yay!