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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; q=dns; s=default; b=Mkgb
	3puJGv0IrQlXtslMZiX2rzpqHTHKdroA/dbyKCya1TLy2ejD6aL/NcmkCExZrpuZ
	QcwJv7fjhXWfk8ZD2yPtyWUZSMcwFGIChM92SXZQdRCwzYR8T4nRGNaCjTkcIlJK
	ElcxvzlGITaZHwr4S9XIeeVYNTJ11rZuAtXYMfk=
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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; s=default; bh=D1qoFinJT7
	yHHNrFZ44zBA5e6XI=; b=yHLdU53MdwPjcHUWmywYgrHNObvGSHYBMpPNBmtmit
	J8ErCyh47NnaltlEWqWsWiXZYtZwz1CqR7MySwI2PycX7nVtXtKjv34mb4oeE6wn
	kp9/upVTSjcjgNn8f3V6Fmqwb4/bSAeT+c6xO485CpzPoxyNu88B81pB7adobDkN
	E=
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=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=07022017, mimic, 07.02.2017, H*f:sk:bba687b
X-HELO:	mout.kundenserver.de
Subject:	Re: [ANNOUNCEMENT] Updated: mintty 2.7.4
To:	cygwin AT cygwin DOT com
References:	<announce DOT 245a59b4-c8dd-31c0-8f79-3b1c8e28a139 AT towo DOT net> <87vasqrl2a DOT fsf AT Rainer DOT invalid> <c377cada-562c-9a5d-14c3-b1f0b204abd5 AT towo DOT net> <25e79ef3-c0ca-2d9f-7353-413580222412 AT SystematicSw DOT ab DOT ca> <52fb66c3-5dc5-afd7-02bf-acdb0a2a9972 AT towo DOT net> <bba687bb-b724-a7d2-2608-3bdc3af772ff AT SystematicSw DOT ab DOT ca>
From:	Thomas Wolff <towo AT towo DOT net>
Message-ID:	<9c13d3fc-9dbd-f89f-05da-28525e0e16e0@towo.net>
Date:	Tue, 7 Feb 2017 21:52:26 +0100
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version:	1.0
In-Reply-To:	<bba687bb-b724-a7d2-2608-3bdc3af772ff@SystematicSw.ab.ca>
X-UI-Out-Filterresults:	notjunk:1;V01:K0:f9sEWNyPsG0=:WzIsSKK6hNyHlfbMUOZ4bR aciyEWtTX81DQAv2v9Ejyl3FrUu4ftxOoSytswTN1+Sicv7PAcm71c+rwaXFJtGn7m6NlNvCF cyBu2xX/AfLT3N2B2/+pD7OxbFJuBW7hYQ/1x0AQMOBzo+x1t1sYWKvXlVUHGHubRfxMR7gHF 2widEZtKs+gtxcdBvnTO1vbqvjxJAghOWS0zyTbxRTUK/11IkNTsgnL50SW79vOrXWAYct5Xq w7Lol+GbHqNebM0zqjnYigCv4CCLEhVIsYeNMDTaS4xDlg9e0dyiR70Kn9fqTJEHQ3QwODuox tRuBWQ6Xedj4565+IfauEX7Hc16tcaEJqWnUds5qb6J3qiuzasbAz8O58zZXFqhhL+072voXt 9unFPb4M3VEKAL7j+cfzbTGzKmyXaZRVQGWt73rbt5PRX+yEAvplMgd1j22IJXUg2Tka1OMGv 8OgKqyjtu9Xi1SS1aXDr7uFZdkJz4I+IMhZMBojmsmeB3xuQpuKHYl3qbKGd+EmpiCeKObmmc odLoyeIagmagE7y9D/Nlnvc670eARc6iPraFRVhH6gjJ7frHcrdNI5EwRDz4YIfHBZxAvQZLt MRoFOTZPN1Vnm4OuSJ8ewe6d0flYPhw4btYdkMzBvpBicr5H7dOy6LMr30pVXQfiHTXnv5J/V LZq8g6vleP7dmJ9abDU+IKXztprM9SaybA5lWYru4DcTr5yGv1zwk4XcKD70DFyxhhMU=
X-IsSubscribed:	yes

--------------FE4EBE731D756DC095D5B936
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Am 07.02.2017 um 08:30 schrieb Brian Inglis:
> On 2017-02-06 12:46, Thomas Wolff wrote:
>> Am 05.02.2017 um 21:36 schrieb Brian Inglis:
>>> On 2017-02-05 11:35, Thomas Wolff wrote:
>>>> Am 04.02.2017 um 17:13 schrieb Achim Gratz:
>>>>> Thomas Wolff writes:
>>>>>> I have uploaded mintty 2.7.4 with the following changes:
>>>>> Since about November/December last year I'm having problems with
>>>>> screen and tmux sessions in mintty not correctly refreshing and
>>>>> leaving garbage characters displayed in the terminal. It seems that
>>>>> the terminal size is not always correctly reported, especially if
>>>>> you make the window occupy the left or right half of the screen via
>>>>> Windows shortcut.
>>>> Is this within tmux or after leaving tmux (see comment below)? It
>>>> would be help to cross-test this; if it's mintty, which version
>>>> would show the behaviour first? What happens in xterm?
>>>>> Additionally, there seems to be an off-by-one bug when the last
>>>>> line of the terminal needs to be scrolled up in order to show
>>>>> content that is longer than the remaining width. This happens when
>>>>> you for instance recall a long command from history. It's hard to
>>>>> see what exactoly happens, but it looks like the one character too
>>>>> many gets printed (and wraps onto the next line) before the whole
>>>>> terminal window gest scrolled up and the rest of the command gets
>>>>> printed in the line below the single wrapped character. That
>>>>> remainder is in various states of disarray, showing both remnants
>>>>> from the original prompt on the last line (now three lines up),
>>>>> empty /spaces where there should have been characters from the
>>>>> command and then of course parts of the command.
>>>> This might be related to some issue with terminal geometry as
>>>> perceived by the shell (see
>>>> https://github.com/mintty/mintty/issues/377#issuecomment-137728631).
>>>> Have you checked that? Recently changed your prompt? Try with basic
>>>> prompt (PS1="\w> ") please.
>>> Thanks for supporting and enhancing mintty to be even better in
>>> Cygwin, and able to be used as a console for other environments.
>>> The test below may be relevant to the above problem, or may be
>>> unrelated.
>>> Running vttest 2.7 (20140305)
>>> http://invisible-island.net/vttest/vttest.html
>>> updated by and used by xterm maintainer for testing.
>>> Test 1. Test of cursor movements screens 3 80 col mode and 4 132 col
>>> mode gives results looking like below ...
>> I was aware this test fails, but save any related bug reports so far
>> I had assumed it would not be relevant for applications...
>> Actually, urxvt (rxvt-unicode as invoked on cygwin) fails the same
>> test in the same way, so @Achim: can you please retest with urxvt,
>> for some additional diagnostic information?
> vttest site documents xterm implements VT100 am/xenl compatibly
> and rxvt and some other consoles do not: ignoring non-print characters
> and sequences until a printable character advances to the next row:
> see:
>
> http://invisible-island.net/vttest/vttest-wrap.html
It's even weirder than that (see also your details provided below); in 
no-Wraparound mode, if you output something to the last column, and the 
cursor is staying in that column, a Backspace will go into the previous 
column (e.g. 79), see the attached test file for some surprising 
results. See below for further comments.


>> Actually, also xterm would fail this test if vttest would not disable
>> Reverse Wraparound mode initially.
>> It also enables Wraparound mode which again affects the test case.
>> Mintty does not support Reverse Wraparound mode disabling, it's
>> always implicitly enabled. I could try to change that, however, I'm
>> not sure yet that's really the cause.
>> Also, the "proper" way to handle wraparound situations (in the 4
>> combinations of the 2 modes) is not completely clear, and Reverse
>> Wraparound is an xterm specific mode which did not exist on the DEC
>> terminals. See some links for reference:
>> bash - An obscure one: Documented VT100 'soft-wrap' escape sequence?
>> - Stack Overflow
> http://stackoverflow.com/questions/31360385/an-obscure-one-documented-vt100-soft-wrap-escape-sequence#31360700
>> XTerm – Frequently Asked Questions (FAQ)
>> http://invisible-island.net/xterm/xterm.faq.html#vt100_wrapping
> My last remaining VT ref seems to be (c) 1987 June DEC EK-VT320-UG-001
> VT320 UG which says on pp.23-24:
>
> "Table 4-4  Display Set-Up Features
> Feature		Settings*	Function
> ...
> Auto Wrap			Selects whether on not text automati-
> 				cally wraps to the next line when you
> 				reach the right margin.
>
> 		*No Auto Wrap*	When the cursor reaches the margin,
> 				the VT320 displays each new charac-
> 				ter/
> /
> Auto Wrap	*No Auto Wrap*	in the last column of the line. Each
> (cont)		(cont)		new character overwrites the previous
> 				character.
>
> 		Auto Wrap	When the cursor reaches the margin,
> 				the VT320 displays new characters on
> 				the next line.
> ...
> *     Default settings are in *bold* type."
>
> [The visual effect of characters "piling up" on the right margin when
> sending 132 character lines at low speed to earlier VT terminals set
> to 80 column width seemed amusing to us at the time, and ensured that
> never happened in our code: Auto Wrap was not the default and never
> assumed or set in anything we used.]
See comments above and attachment for the consequences of this 
behaviour; they are logically consistent but still very weird.
I could change mintty to mimic this behaviour, but I'd need some 
evidence that this would solve some real-world issues before I take the 
risk of possibly breaking other applications.
Further comments welcome, and it's Achim's turn to provide further 
diagnostics input as requested in another mail. It could also be that 
screen or tmux simply make invalid assumptions about the setting of 
Wraparound modes.
------
Thomas

>
>> VT100 Termcap Entry (CENG 455)
>> http://www.pitt.edu/%7Ejcaretto/text/cleanup/vt100-termcap.html

--------------FE4EBE731D756DC095D5B936
Content-Type: application/octet-stream;
 name="vt-wraparound"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="vt-wraparound"

G1s/M2wbWz80NWgbWz83aCBXcmFwYXJvdW5kOiB5ZXMgUmV2ZXJzZSBXcmFw
YXJvdW5kOiB5ZXMKMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz
NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4
OTAIG1s0NG14eRtbMG0KMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkw
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1
Njc4OTAxCAgbWzQ0bXh5G1swbQoxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1
Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkw
MTIzNDU2Nzg5MAoICBtbNDRteHkbWzBtChtbPzQ1aBtbPzdsIFdyYXBhcm91
bmQ6IG5vICBSZXZlcnNlIFdyYXBhcm91bmQ6IHllcwoxMjM0NTY3ODkwMTIz
NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4
OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MAgbWzQ0bXh5G1swbQoxMjM0NTY3ODkw
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1
Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEICBtbNDRteHkbWzBtCjEyMzQ1
Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkw
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwCggIG1s0NG14eRtbMG0K
G1s/NDVsG1s/N2ggV3JhcGFyb3VuZDogeWVzIFJldmVyc2UgV3JhcGFyb3Vu
ZDogbm8KMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5
MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAIG1s0
NG14eRtbMG0KMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2
Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx
CAgbWzQ0bXh5G1swbQoxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx
MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2
Nzg5MAoICBtbNDRteHkbWzBtChtbPzQ1bBtbPzdsIFdyYXBhcm91bmQ6IG5v
ICBSZXZlcnNlIFdyYXBhcm91bmQ6IG5vCjEyMzQ1Njc4OTAxMjM0NTY3ODkw
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1
Njc4OTAxMjM0NTY3ODkwCBtbNDRteHkbWzBtCjEyMzQ1Njc4OTAxMjM0NTY3
ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEy
MzQ1Njc4OTAxMjM0NTY3ODkwMQgIG1s0NG14eRtbMG0KMTIzNDU2Nzg5MDEy
MzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3
ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAKCAgbWzQ0bXh5G1swbQo=


--------------FE4EBE731D756DC095D5B936
Content-Type: text/plain; charset=us-ascii


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
--------------FE4EBE731D756DC095D5B936--

- Raw text -