This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] Updated: mintty 2.7.4
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
> 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.]
> VT100 Termcap Entry (CENG 455)
> http://www.pitt.edu/%7Ejcaretto/text/cleanup/vt100-termcap.html
>> It may also be useful if mintty had some character hex value box
>> display mode switch to display the actual codes at each visual
>> position, or maybe a font used to display the character hex value in
>> a box, often used in fonts as glyphs for non-printing control
>> characters and those in the Private Use Area, in which case that could
>> perhaps be added to the mintty package for use in testing.
>> I have been searching for such a font with no success so far.
> Hmm, I don't see how that's related to this issue, but it might be a
> nice feature.
Displaying the character set codes passed to the console.
> Like my text editor, mined, actually does: inform about current
> character code and name (and CJK details if desired).
> I could imagine to have a mode (switchable by context menu) that
> shows this information in the window title bar, to avoid the effort
> of handling a popup box.
I did some further searching after the previous post and found the right
search keyword combo for "diagnostic" fallback fonts:
. Unicode BMP Fallback Font displays each character in the BMP as hex
within a square box:
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=UnicodeBMPFallbackFont
. Unicode Last Resort font developed for Unicode on behalf of Apple
displays the same representative glyph indicating its type within a
thick rounded box for all characters of the same class or script; in
large sizes the character type and range are visible within the box
edges:
http://unicode.org/policies/lastresortfont_eula.html
. GNU Unifont provides low quality bitmapped style 8x16 or 16x16 fallback
glyphs for all BMP characters and are working on increasing SMP support:
https://savannah.gnu.org/projects/unifont
Those interested can download, install, and check these out in Windows
Charmap, using Group by Unicode Subrange, to see what they provide and
how they could be used for diagnostic fallback.
--
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