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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=f/NKPyWphzl204cn4j91qZ2+Ws+3Th2O2W6cM4MG8vCZpENtsPe6L
	3mQnJzhdkeGX3jXBjaXwHgjzE8b8Pd8/EOYLqU3/70SCj67WpLrxFzrRGIxgbOGs
	E5Kx00ENjEg7ds9YiRDk112VzSFypO3TGfCl2rW8rrUif4Y0XmuRwE=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=jiCDNbRBZrCSqw4vpZtJftYYY2Q=; b=Zs+tCXd0X6HLc08koBazB02boF+n
	cioVMDLtcfVmrhA2PRG7ORWVfKb2E3qG2dA+HQyGo6ebgv+NlmZiSm30YBgEz0r4
	wGaWYb7ndoTJVK55VybHKBTFkK5d60DZKofZbfFQ7ykSyWD+jhQudXAjZEBjqUwV
	3J8TSAPWSO94hZE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-95.0 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BRBL_LASTEXT,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=H*f:sk:0ee6699, H*i:sk:0ee6699
X-HELO:	calimero.vinschen.de
Date:	Thu, 28 Jul 2016 21:51:35 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
Message-ID:	<20160728195135.GC26311@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<0ee6699f198b7b0f588054ba2f829db5 AT mail DOT kylheku DOT com>
MIME-Version:	1.0
In-Reply-To:	<0ee6699f198b7b0f588054ba2f829db5@mail.kylheku.com>
User-Agent:	Mutt/1.6.2 (2016-07-01)

--OBd5C1Lgu00Gd/Tn
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> Hi Corinna,
>=20
> 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.
>=20
> 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.
>=20
> Finally, restore the cursor position.
>=20
> 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.
>=20
> However, there are possible arguments against trimming blank
> lines which are above the cursor position. Say the window
> contains this:
>=20
>    +---
>    | nonblank
>    | blank
>    | blank
>    | > [] cursor
>    | blank
>    | blank
>    | blank
>    +---
>=20
> 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".
>=20
> 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
   | >=20
   | 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

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

--OBd5C1Lgu00Gd/Tn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXmmJHAAoJEPU2Bp2uRE+gX1QP/1XKkVd/djIcVZvXnUruOTr0
7sPobsX2IDW71cgPussHvPcM3R6TltaYaALjCgddL1ION99oKyjLyywafB8XhCXu
o8cdKE5pNTrXofnq6tYWlEsV2/p4hD/QrrHTN4hygo6ox01/AbUkO3zv5bJxpp4Z
G+nqsL7xJMFgv/6m2UMvp8g8ZQWbWy5iwLYGanozIbVxErBUop4edg1PXTXIJdss
OOproiP9AL8P7FsF0CMnCw8Qjp3tSQtbF9j3g7BsgO2Na0hJx2hfruRxoiWHoT1w
P1MWUZn5oaMJQF/TznTAp6g+S3ck+gMsgjeoGZJQLGaUUqWGPv6/+/6p2TpE5MyU
OoFL6F9EsSdLeZ7Oe53rznBeuCz8Ql17NdA9V8c9mVSF1ZpMs++jUhrbENoVWQqi
XGDk322LSovwJu4y/FsMXVUJgwsV6J7pFJY+uiPV4UdvRdirJ4ZfFvktGpoIRLmO
7lb7XAcGvnC2DTGjTubv/lXsq2cNff1ACfVBm2zoqas2gLCtxFWXuIqZIt/Vi0LB
4G6nDaSPl4/Qn0XMkPq9sHEdEiL7+WQl5LmC40Ndap7rrkkMLSrc06gMcNwwdQws
TS6U6bmAGGdEkn+6j+LmHs9PB7kTTkE9MTQ2QDyiX5Sw2gaWw6njQC9a7ieWCM7n
fGdFR7INshA/qWA/LS0U
=TWf3
-----END PGP SIGNATURE-----

--OBd5C1Lgu00Gd/Tn--

- Raw text -