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
signature.asc
Description: PGP signature
