Re: [PATCH v3 0/1] Pseudo console support in PTY (v3)

[Thomas Wolff <towo at towo dot net>]

Hi Takashi,

> The major changes from v2 is as follows.
My testing showed the following observations.
> ...
>
> (3) Code page handling is refined a bit. Now, code page 65001 (UTF8)
>       and native code page in your region should work without garbled
>      characters. This works properly only on terminal which supports
>      UTF-8.
Character output conversion works with my test program (using 
WriteConsoleW). Using java, output works too (with proper java encoding 
option), but non-ASCII input characters are replaced by and echoed as space.

If I try a non-Unicode terminal session, e.g. running mintty -o Locale=C 
-o Charset=CP1252 -, and enter a € key, mintty hangs. While you said it 
doesn't work (yet), it should better not hang at least. I'd like to 
repeat at this point that the whole mechanism should only be applied if 
a non-cygwin program is run. (If it were, entering € in bash would not 
block the terminal.)

> (4) Synchronization between real terminal and pseudo console screen
>      buffer is improved. For this, screen is cleared on startup of pty
>      slave app. Also echo for key input is pushed into pseudo console
>      screen buffer.
Do you actively synchronize anything? I thought this is not needed 
anymore (unlike winpty) because the ConPTY performs the adaptation.

Terminal reports "\033[6n" and "\033[0c" are apparently emulated and 
sent in reverse order;
response to primary device attribute request is wrong (not what mintty 
would report).
There is no response to secondary device attribute request ("\033[>0c") 
and others,
e.g. '\033[18t' or '\033]10;?\033\' and many others; why can't these 
requests be passed to the terminal and handled transparently? (You 
explained something around handles before but I don't get the point.)

Output to alternate screen seems to be forced to the primary screen, mostly;
if I try to switch screen in various ways (menu, echo "\033[?1047h" > 
/dev/pty1, before or while cmd.exe runs),
behaviour appears to be inconsistent and not as expected (expected 
behaviour is that any output goes to the active screen). Again, I don't 
see a need that you intercept this at all.

Thomas