[PATCH v3 0/1] Pseudo console support in PTY (v3)
Sat Apr 6 21:33:00 GMT 2019
> 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
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
There is no response to secondary device attribute request ("\033[>0c")
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.
More information about the Cygwin-developers