On Aug 2 23:19, Kaz Kylheku wrote: > 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.
I could reproduce this now and I think I have fixed it. There's still a problem with the position of the scrollbars in certain scenarios where they are off by about one window size. I added a FIXME comment. I have to admit I'm very puzzled that neither SetConsoleWindowInfo nor the subsequent SetConsoleCursorPosition automatically set the scrollbars correctly. That's what I would expect, naively. If anybody knows how to fix the scrollbar position in a Windows console without moving the window contents around, please help. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
signature.asc
Description: PGP signature
