From: Kaz Kylheku <kaz@kylheku.com>
To: Corinna Vinschen <corinna-cygwin@cygwin.com>
Cc: cygwin@cygwin.com
Subject: Re: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
Date: Wed, 03 Aug 2016 11:55:00 -0000 [thread overview]
Message-ID: <7c08fa896bb7dadcca91f1a7a26ddf20@mail.kylheku.com> (raw)
In-Reply-To: <20160801085109.GC3470@calimero.vinschen.de>
On 01.08.2016 01:51, Corinna Vinschen wrote:
> On Jul 29 08:59, Kaz Kylheku wrote:
>> On 29.07.2016 03:39, Corinna Vinschen wrote:
>> > I applied a patch to perform this action. It's in the latest
>> > 2.6.0-0.5 test release I just announced.
>> [...]
>> I've done some interactive testing with this using
>> the interpreter for a Lisp dialect. I would evaluate
>> this expression to generate a 5 second delay and then
>> a clear screen VT100 sequence:
>>
>> (progn (usleep 5000000) (put-string "\e[2J"))
>>
>> during this time, I would scroll the buffer somewhere.
>>
>> I also tested with a cursor position somewhere in the
>> middle of the window, having issued:
>>
>> (put-string "\e[12H")
>>
>> The programming language details don't matter; we
>> could do this with bash echo $'\e...' and sleep 5.
>> [...]
>> With the third patch, I've run into behavior in which the
>> display isn't cleared at all if the clear is issued
>> in a scrolled-back state.
>
> I can't reproduce this. If I don't click wildly on the scroll bat at
> the time the clear screen action takes place (so I move the window
> right
> after clear screen), the cursor is positioned at the top of the screen,
> at the end of the buffer. So, how would I reproduce your observation
> so
> that all window positioning is guaranteed to take place *before* the
> clear screen action and still see the broken output?
Hi Corinna,
I have figured out how to reproduce it. There are two
necessary conditions. No, three:
1. You must scroll the display all the way to the top
as far as you can before the clear screen is issued.
2. The scrollback history must be full. I.e., this
won't happen in a fresh cmd.exe window. First, print
thousands of lines of stuff to make the buffer "tall".
This is why it only started happening to me after some
amount of testing; I had filled the buffer.
3. It's probably a necessary condition that there is additional
output immediately after the clear screen (such as the
programming language prompt being printed), because
the console scrolls to bottom on any output.
I'm not sure if these are sufficient, but they seem to be
on my end.
This is perhaps some kind of race condition between the scrolling
issued by cmd.exe, and the scrolling issued by the console API.
Or maybe not a race, as such, but some backlog-processing logic.
Perhaps the console simply drops scroll actions that it hasn't
had time to perform. The API-requested scroll is thrown in the
bit bucket, superseded by the scroll-to-bottom on output.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
WARNING: multiple messages have this Message-ID
From: Kaz Kylheku <kaz@kylheku.com>
To: Corinna Vinschen <corinna-cygwin@cygwin.com>
Cc: cygwin@cygwin.com
Subject: Re: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
Date: Wed, 03 Aug 2016 12:41:00 -0000 [thread overview]
Message-ID: <7c08fa896bb7dadcca91f1a7a26ddf20@mail.kylheku.com> (raw)
Message-ID: <20160803124100.Sp75j-uw29FirAd_NaE8FRT-FfnrP-eKQDqinfsYtiI@z> (raw)
In-Reply-To: <20160801085109.GC3470@calimero.vinschen.de>
On 01.08.2016 01:51, Corinna Vinschen wrote:
> On Jul 29 08:59, Kaz Kylheku wrote:
>> On 29.07.2016 03:39, Corinna Vinschen wrote:
>> > I applied a patch to perform this action. It's in the latest
>> > 2.6.0-0.5 test release I just announced.
>> [...]
>> I've done some interactive testing with this using
>> the interpreter for a Lisp dialect. I would evaluate
>> this expression to generate a 5 second delay and then
>> a clear screen VT100 sequence:
>>
>> (progn (usleep 5000000) (put-string "\e[2J"))
>>
>> during this time, I would scroll the buffer somewhere.
>>
>> I also tested with a cursor position somewhere in the
>> middle of the window, having issued:
>>
>> (put-string "\e[12H")
>>
>> The programming language details don't matter; we
>> could do this with bash echo $'\e...' and sleep 5.
>> [...]
>> With the third patch, I've run into behavior in which the
>> display isn't cleared at all if the clear is issued
>> in a scrolled-back state.
>
> I can't reproduce this. If I don't click wildly on the scroll bat at
> the time the clear screen action takes place (so I move the window
> right
> after clear screen), the cursor is positioned at the top of the screen,
> at the end of the buffer. So, how would I reproduce your observation
> so
> that all window positioning is guaranteed to take place *before* the
> clear screen action and still see the broken output?
Hi Corinna,
I have figured out how to reproduce it. There are two
necessary conditions. No, three:
1. You must scroll the display all the way to the top
as far as you can before the clear screen is issued.
2. The scrollback history must be full. I.e., this
won't happen in a fresh cmd.exe window. First, print
thousands of lines of stuff to make the buffer "tall".
This is why it only started happening to me after some
amount of testing; I had filled the buffer.
3. It's probably a necessary condition that there is additional
output immediately after the clear screen (such as the
programming language prompt being printed), because
the console scrolls to bottom on any output.
I'm not sure if these are sufficient, but they seem to be
on my end.
This is perhaps some kind of race condition between the scrolling
issued by cmd.exe, and the scrolling issued by the console API.
Or maybe not a race, as such, but some backlog-processing logic.
Perhaps the console simply drops scroll actions that it hasn't
had time to perform. The API-requested scroll is thrown in the
bit bucket, superseded by the scroll-to-bottom on output.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
next prev parent reply other threads:[~2016-08-03 6:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-28 19:44 Kaz Kylheku
2016-07-28 19:51 ` Kaz Kylheku
2016-07-28 19:59 ` Corinna Vinschen
2016-07-28 20:21 ` Corinna Vinschen
2016-07-29 13:25 ` Corinna Vinschen
2016-07-29 20:51 ` Kaz Kylheku
2016-07-29 21:03 ` Kaz Kylheku
2016-08-01 8:51 ` Corinna Vinschen
2016-08-03 11:55 ` Kaz Kylheku [this message]
2016-08-03 12:41 ` Kaz Kylheku
2016-08-03 16:53 ` Corinna Vinschen
-- strict thread matches above, loose matches on Subject: below --
2016-07-27 5:19 Kaz Kylheku
2016-07-27 13:09 ` Kaz Kylheku
2016-07-27 14:32 ` [PATCH] " Kaz Kylheku
2016-07-27 14:35 ` Kaz Kylheku
2016-07-27 15:40 ` Kaz Kylheku
2016-07-27 18:45 ` Corinna Vinschen
2016-07-27 20:36 ` Kaz Kylheku
2016-07-27 21:30 ` Kaz Kylheku
2016-07-28 8:00 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c08fa896bb7dadcca91f1a7a26ddf20@mail.kylheku.com \
--to=kaz@kylheku.com \
--cc=corinna-cygwin@cygwin.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).