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:references:to:from:reply-to:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=L2CLct5DelaTID1J
	A4xWMm/N8YaZBaCvBMP/lxGVR8oamtOz8fqhgCCuOm/AF9iNcQw5tqPTYUPUghA2
	LzLWgPtOMLqCzkn00YXFGfEiRxhwN3WCmkRzuRFbaz3Tvk8Rf8+3CyeOJ5lrI1un
	QDQNoJQUUBiYtn8SJY24hM0ucmc=
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:references:to:from:reply-to:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=hfIcjXDu0G23i7RqMbYRXF
	m/jI4=; b=pdAJ8JLdqtTML1nq5hvB/5c2UfWBOrED6Q2OcsGXO2dfPPHdFiJPqE
	bAakJi8VWNoT1Wnw67pmr5H1QYOXiitNY4CpNEHa8dJcz/MHq0pXi2hf5XX+V6KN
	VCHy5R8WoAHmWLLkmOv0jGQK5A34tyXb1XEqkiiALGA/cDR2rgRr4=
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=1.3 required=5.0 tests=AWL,BAYES_40,KAM_ASCII_DIVIDERS,KAM_LAZY_DOMAIN_SECURITY,KAM_LOTSOFHASH,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:64.59.134.9, H*RU:64.59.134.9, blanks, H*r:sk:smtp-ou
X-HELO:	smtp-out-no.shaw.ca
X-Authority-Analysis:	v=2.2 cv=BNTDlBYG c=1 sm=1 tr=0 a=WqCeCkldcEjBO3QZneQsCg==:117 a=WqCeCkldcEjBO3QZneQsCg==:17 a=IkcTkHD0fZMA:10 a=NEAV23lmAAAA:8 a=HiWkEfo4AAAA:8 a=uPZiAMpXAAAA:8 a=YQbWNNo_3Ey30rcncGQA:9 a=QEXdDO2ut3YA:10 a=NGto_iE5OMEA:10 a=5hOciU1D_GEA:10 a=4zpMnB1xO2oA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 a=_QplDg0m8TGAdENQf2wZ:22 a=svzibyHiZmA4t4YY0eFS:22
Subject:	Re: [ANNOUNCEMENT] Updated: mintty 2.7.4
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> <9c13d3fc-9dbd-f89f-05da-28525e0e16e0 AT towo DOT net>
To:	cygwin AT cygwin DOT com
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Reply-To:	Brian DOT Inglis AT SystematicSw DOT ab DOT ca
Message-ID:	<86782637-b845-94a6-4aac-abf6242c77a0@SystematicSw.ab.ca>
Date:	Tue, 7 Feb 2017 19:17:38 -0700
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:	<9c13d3fc-9dbd-f89f-05da-28525e0e16e0@towo.net>
X-CMAE-Envelope:	MS4wfKUGJIutvn9Fbu6WtwMaNkefJX9gp2Wm96b6AvTNGrt8vvqyLj3CHVNSCeplDGOdzHffRUZsJ9l0G9BhPjZK3OWSEGQJQnevNolqRM6VaHz2KSrYx/kS fMn+5HGSP7ohdf5KkkMLk+fFo+5dhk9gATq5+6rwKevMWULMCeYv8++2bQ67ju1r4boYuJa6kCmjew==
X-IsSubscribed:	yes

On 2017-02-07 13:52, Thomas Wolff wrote:
> 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.

Scenarios 1 and 3 look the same to me in mintty, as do 2 and 4; all x and y have 
a coloured bg as do the blanks in the first line with y in 1 and 3, whereas the 
second line with y in 1 and 3 has blanks with normal background colour (I use 
standard white background windows in consoles, so changed the colour from 44 blue 
to 42 green to see the characters): 

================================================================================
 Wraparound: yes Reverse Wraparound: yes
1234567890123456789012345678901234567890123456789012345678901234567890123456789x
y
1234567890123456789012345678901234567890123456789012345678901234567890123456789x
y
123456789012345678901234567890123456789012345678901234567890123456789012345678xy
 Wraparound: no  Reverse Wraparound: yes
1234567890123456789012345678901234567890123456789012345678901234567890123456789y
123456789012345678901234567890123456789012345678901234567890123456789012345678xy
12345678901234567890123456789012345678901234567890123456789012345678901234567890
xy
 Wraparound: yes Reverse Wraparound: no
1234567890123456789012345678901234567890123456789012345678901234567890123456789x
y
1234567890123456789012345678901234567890123456789012345678901234567890123456789x
y
123456789012345678901234567890123456789012345678901234567890123456789012345678xy
 Wraparound: no  Reverse Wraparound: no
1234567890123456789012345678901234567890123456789012345678901234567890123456789y
123456789012345678901234567890123456789012345678901234567890123456789012345678xy
12345678901234567890123456789012345678901234567890123456789012345678901234567890
xy
$ 
================================================================================

It seems like the best approach may be the preferred answer in your quoted link:

http://stackoverflow.com/questions/31360385/an-obscure-one-documented-vt100-soft-wrap-escape-sequence?answertab=votes#tab-top

- as readline does, add a space when you display in the right margin position;
if you don't get one from the app, add one yourself?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

- Raw text -