This is the mail archive of the cygwin 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]

Re: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.

On 29.07.2016 03:39, Corinna Vinschen wrote:
On Jul 28 21:51, Corinna Vinschen wrote:
However, the former cursor position in the buffer is still known
at clear screen time.  It's stored in dev_console::dwEnd.  So what
I was thinking about is to check the above situation and then, rather
then to just keep it as is, move the console window  and the cursor
position up to the line right after the former cursor position, i.e:

After (desired?):

   | nonblank
   | nonblank
   | blank
   | blank      window
   | >          ---+
   | > [] cursor   |
   | blank         |
   | blank      ---+
   | blank
   | blank
   | blank
   | blank

Does that make sense or am I still missing something?

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.

In terms of the final appearance of the terminal window,
the best results are obtained using the naive newline
ejection method! The screen is clear, and the cursor is at
the proper *window* position. (That's what we care about
in VT100-land; we don't care about Windows console buffer
semantics, and the position in the abstract buffer; position
means screen position.)

Your first patch has the effect that the physical screen position
is not always restored. The window is clear, but the cursor
is sometimes at the bottom, even though it was somewhere
in the middle of the window before the operation. In the
abstract buffer coordinates, it is correct; it's just that
the window viewport is not all the way down.

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.

The naive newline ejection, in spite of its flaw of adding
more blank lines to the history than one would like,
achieves the best visual results in all cases because
the viewport jumps to the bottom of the buffer when the
newlines are being emitted, and then the cursor position
is restored in that viewport position.

Cheers ...

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]