This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

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
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
Running vttest 2.7 (20140305)
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:
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
XTerm – Frequently Asked Questions (FAQ)
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-
Auto Wrap	*No Auto Wrap*	in the last column of the line. Each
(cont)		(cont)		new character overwrites the previous

		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.

VT100 Termcap Entry (CENG 455)

Attachment: vt-wraparound
Description: Binary data

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]