X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:subject:mime-version:content-type :content-transfer-encoding:date:from:cc:in-reply-to:references :message-id; q=dns; s=default; b=gkTtCqFD/B//BJZ9GoAaVj6qdxaO6Js 14KqOavdnapmq6sJjpxH0+WwDI3hvlzku9W9CsaZ4pQvgmBgJnAKroo1H4tOH0sG ChhkXpdl3wqPB0Xn7prBcMGiLUtYE9T9EMS5uM0/NQ89VMRoxh8d5dIOjAvWfFth 7KWMHrdeA/bk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:subject:mime-version:content-type :content-transfer-encoding:date:from:cc:in-reply-to:references :message-id; s=default; bh=pyO5pOzTwxOmcNoO4R0Hu3gks5o=; b=reps1 FsYhu3aRpL8HDjhHA6z1XyWkvGUnnctrryxh4KgELbk4SaiRIiRBUi33PEgfsHz4 p0Nd0p+q5xWvYPIj7KLFEHILWGArV6gAUdCHOqrrj57rOy0Ofsuxg29k2zqb+H8c QoXAOfZQkSWTgOSjnWlZxS57qqQ+ISlmi18zyM= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Delivered-To: corinna-cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=tall, HX-PHP-Originating-Script:501, Hx-spam-relays-external:64.59.134.9, observation X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp-out-no.shaw.ca X-Authority-Analysis: v=2.2 cv=GdZVpkfL c=1 sm=1 tr=0 a=WiYoHcCliNeVponEdG0Ckg==:117 a=WiYoHcCliNeVponEdG0Ckg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=7z1cN_iqozsA:10 a=JU3C8Zs9boJx8Qh7sxAA:9 a=gtt2rF1ZOiHY3bda:21 a=8bbOdes_x7hiBaMv:21 To: Corinna Vinschen Subject: Re: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program. X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Tue, 02 Aug 2016 23:19:20 -0700 From: Kaz Kylheku Cc: cygwin AT cygwin DOT com In-Reply-To: <20160801085109.GC3470@calimero.vinschen.de> References: <0ee6699f198b7b0f588054ba2f829db5 AT mail DOT kylheku DOT com> <20160728195135 DOT GC26311 AT calimero DOT vinschen DOT de> <20160729103927 DOT GB5963 AT calimero DOT vinschen DOT de> <20160801085109 DOT GC3470 AT calimero DOT vinschen DOT de> Message-ID: <7c08fa896bb7dadcca91f1a7a26ddf20@mail.kylheku.com> X-Sender: kaz AT kylheku DOT com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfDep5ei1EKZZGq6rQQH0zp0ICe5kjZ9pZtYvrpEJSjh80x8zwUS48mfb5s+xXkURceqRbYBKHbmhw5oklW6cYT7Q8/VkETMirv5EwwvAC407N5Szv30g PRy1MVrSUF8pLvhr04Gxv22xz/CLj6855BgM48b5oR1SiW2e6AmdpEIZqGhielFgHypFmess8Ma/qw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u736K5ah013660 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