This is the mail archive of the cygwin-developers mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Am 16.08.2018 um 10:54 schrieb Johannes Schindelin:
Sure, I wasn't suggesting winpty might become obsolete. I only meant to refer to the "implicit winpty injection" solution I had suggested to be embedded into cygwin. With ConPTY, cygwin might provide better integration of native Windows apps at least on newer Windows systems.Hi Thomas, On Thu, 16 Aug 2018, Thomas Wolff wrote:Am 09.04.2018 um 11:57 schrieb Corinna Vinschen:On Apr 6 21:22, Johannes Schindelin wrote:On Fri, 6 Apr 2018, Thomas Wolff wrote:Am 06.04.2018 um 12:31 schrieb Johannes Schindelin:On Fri, 6 Apr 2018, Thomas Wolff wrote:These symptoms suggest to me: winpty is not the culprit, but its presence in the invocation chain seems to trigger the effect in a yet unclear way.Sure, `winpty` is not the culprit.Actually, as it turns out, winpty *is* the culprit. I've raised winpty issue https://github.com/rprichard/winpty/issues/140 about it.I am not sure you understand the issue here. The `winpty` helper opens a Win32 console for the native Windows application to use. Then it polls this (hidden) console for changes and tries to reflect them in the Cygwin pty. If that Windows application writes something to that console containing Escape sequences, then those Escape sequences occupy certain cells in that matrix of rows and columns making up that console. However, if the Windows application uses random-access functions to put individual characters into cells specified by given absolute positions, winpty cannot tell the difference. So what winpty would be asked to consider an ANSI sequence may never have been an ANSI sequence. Sure, this is a construed example, but it shows that you should not be so sure that winpty *can* detect ANSI sequences and handle them in a way that *you* want. [...] In the least, therefore, it should be configurable. And I would even argue that the default behavior should remain the same as current in Cygwin: do not use winpty by default. Of course, this is just my opinion, and I am but a user and infrequent contributor to Cygwin. But I would hope that the Cygwin maintainers use a lot of care and reluctant deliberation when considering a potentially disruptive change such as this, a change that may very well occupy a lot of time in dealing with the unwanted fallout.Point taken. Nicely explained. However, that makes calling winpty from Cygwin a somewhat questionable endeavor. Adding optional code paths which are in all likelyhood not used very often, thus not tested very often, thus bound to rot, are not really something I'm looking forward to.It seems that the new Windows ConPTY API will be a more reliable solution to these issues: https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/And of course this will not apply to any Windows 7 or Windows 8 users. Or to users who are for some reason stuck with a Windows 10 that is not updated to the latest and greatest update. Don't get me wrong, I am delighted what my colleagues do there, they are doing great work, and Windows 10 will offer very nice features that Cygwin can use to make things more reliable and/or faster. Cygwin wants to support more Windows versions, though, so winpty will still be needed, methinks.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |