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 Jul 28 09:36, Kaz Kylheku wrote:
> On 28.07.2016 00:08, Corinna Vinschen wrote:
> > Thanks for testing.  I'll check in the patch as is for now, but I'd
> > still be interested to fix the aforementioned empty lines problem,
> > even if just for completeness.  If you have an idea, feel free to
> > propose.
> 
> Hi Corinna,
> 
> The blank lines above the cursor position, as well as any
> that are below, are entering into the history simply because they
> are part of the window content being saved. Any non-blank lines
> in their place would be expected to be saved, and no processing
> takes place to distinguish blank from non-blank.
> 
> One way to address this is to basically scan the entire window
> portion of the buffer for trailing blank lines and trim the buffer
> to exclude them. Then scroll by the amount of remaining lines
> lines, to usher them into the history.
> 
> Finally, restore the cursor position.
> 
> Or, perhaps, two or more trailing blank lines in the window could be
> condensed down to one which does get saved, so the separation
> is not misleadingly condensed down to nothing.
> 
> However, there are possible arguments against trimming blank
> lines which are above the cursor position. Say the window
> contains this:
> 
>    +---
>    | nonblank
>    | blank
>    | blank
>    | > [] cursor
>    | blank
>    | blank
>    | blank
>    +---
> 
> It's uncontroversial to obliterate the three blank lines below the
> cursor. However the blank lines between the nonblank line and
> the cursor could be semantic; the user might want them in the
> scrollback history "as is".
> 
> The leading nonblank line is a red herring; even if all the
> lines above the cursor are blank, the reasoning applies.

The situation I was thinking about is a bit different.  Consider an only
partially filled console buffer.  In contrast to your typical UNIX
terminal application the buffer doesn't grow.  It's a fixed size and the
scroll bar reflects this buffer size right from the start.  So the user
can scroll the console windows down into the not yet used buffer area,
i.e.:

Before:

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

Performing the clear screen in this situation, the cursor will be
repositioned to the first line in the current window and the blank lines
between the old cursor position and the new cursor position

After (now):

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

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?):

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

Does that make sense or am I still missing something?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature


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