[ANNOUNCEMENT] Updated: mintty 2.7.4

Brian Inglis Brian.Inglis@SystematicSw.ab.ca
Wed Feb 8 02:17:00 GMT 2017

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
 Wraparound: no  Reverse Wraparound: yes
 Wraparound: yes Reverse Wraparound: no
 Wraparound: no  Reverse Wraparound: no

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


- 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

More information about the Cygwin mailing list