From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24415 invoked by alias); 8 Feb 2017 02:17:52 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 24405 invoked by uid 89); 8 Feb 2017 02:17:51 -0000 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 Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Feb 2017 02:17:41 +0000 Received: from [192.168.1.100] ([174.0.238.184]) by shaw.ca with SMTP id bHpCcOibMVQuxbHpEcX0zH; Tue, 07 Feb 2017 19:17:40 -0700 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.fsf@Rainer.invalid> <25e79ef3-c0ca-2d9f-7353-413580222412@SystematicSw.ab.ca> <52fb66c3-5dc5-afd7-02bf-acdb0a2a9972@towo.net> <9c13d3fc-9dbd-f89f-05da-28525e0e16e0@towo.net> To: cygwin@cygwin.com From: Brian Inglis Reply-To: Brian.Inglis@SystematicSw.ab.ca Message-ID: <86782637-b845-94a6-4aac-abf6242c77a0@SystematicSw.ab.ca> Date: Wed, 08 Feb 2017 02:17:00 -0000 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 X-SW-Source: 2017-02/txt/msg00103.txt.bz2 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