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: List-Subscribe: List-Archive: List-Post: List-Help: , 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: <87vasqrl2a DOT fsf AT Rainer DOT invalid> <25e79ef3-c0ca-2d9f-7353-413580222412 AT SystematicSw DOT ab DOT ca> <52fb66c3-5dc5-afd7-02bf-acdb0a2a9972 AT towo DOT net> <9c13d3fc-9dbd-f89f-05da-28525e0e16e0 AT towo DOT net> To: cygwin AT cygwin DOT com From: Brian Inglis 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> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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