Re: [PATCH] Improve Windows tty/pty detection

[Thomas Dickey]

On Sat, Jul 15, 2023 at 01:57:36AM +0300, Pavel Fedin wrote:
>  Hello again! Please consider my second patch to fix the second problem.
> 
>  The problem is: MinGW uses MinTTY as its primary console. MinTTY is capable
> of full terminal emulation; but unfortunately terminfo driver (using
> traditional control codes) doesn't work on Windows. I can't tell the exact
> reason for that; i remember it worked back in Windows 8 times, but now
> attempt to use it simply ends up in a garbled display. Probably due to some
> conflict with some Windows 10's own processing.

thanks - I'll have to investigate this: most of my attention has been on
the target environments (e.g., Console API, and Windows Terminal).

I'm aware that the development shells for MinGW and MSYS2 use ncurses, but 

a) haven't had a problem running ncurses applications in the MSYS2 development
   shell (I've been using ded and vile in that for several years).

b) had more/less ignored changing the development shell of MinGW because
   it relies upon development libraries not published.

   See my comment here about termcap:

   https://invisible-island.net/personal/cross-mingw.html#cross_vile

c) the development shells for MinGW and MSYS2 aren't the same :-)
 
>  The way to go is to prefer using API driver whenever possible. Since Aug
> 2019 ConPTY support has been integrated into Cygwin, and MinGW as a
> consequence; see
> https://github.com/mintty/mintty/issues/56#issuecomment-526170062 .

That appears to mention MSYS2 rather than MinGW.

> Therefore there's no more need to use control codes in MinTTY; we can always
> use API driver and it will work. MinTTY will get console events and react
> accordingly.
> 
>  Why setting $TERM to "#win32console" is not a good solution:
> 
> 1. MinGW consists of two environments: MinGW and MSYS. MSYS is full

...but you're describing their development shells.
Neither of those use Console API.

> UNIX-alike; in fact it's a tailored version of Cygwin. MSYS build of ncurses
> only relies on control codes; it does not use API driver. Somehow it works
> fine in this configuration; again, i don't know why MinGW configuration
> doesn't work. Both environments share the same MinTTY with the same config.
> Setting TERM to #win32console works fine in MinGW shell, but totally kills
> TUI in MSYS shell with the message
> 
> Error opening terminal: #win32con
> 
> 2. There are some small tools, like "clear", which solely rely on control
> codes. And they need $TERM to be set to real terminal name. Again, setting
> "#win32con" totally kills those tools:
> 
> '#win32con': unknown terminal type.

I think that's in the README:

https://github.com/ThomasDickey/ncurses-snapshots/blob/ffbd62551a2a7afb337016e361f83e573155be8e/README.MinGW#L63

>  The suggested patch relies on SysISATTY() macro to detect whether our fd is
> a console or not. _isatty() successfully detects pseudo-consoles using
> ConPTY. If the console is detected, WinAPI driver accepts the terminal
> regardless of $TERM variable. Some more notes on the implementation:
> 
> 1. CON.isMinTTY removed, because i found out that it does nothing.
> 
> 2. I decided not to include _ismintty() test because frankly speaking i
> don't understand why it's there. See the preamble above, MinTTY makes use of
> ConPTY support, so it's correctly detected as console. There's no need to
> perform an explicit check. Perhaps it's obsolete.
> 
> 3. Again, i only touched old, production driver. It's up to you to decide
> whether this change also fits the new experimental driver.

...on my to-do list

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

signature.asc
Description: PGP signature