[ANNOUNCEMENT] Updated: mintty 2.7.4

[ANNOUNCEMENT] Updated: mintty 2.7.4

[Thomas Wolff]

I have uploaded mintty 2.7.4 with the following changes:

Localization details:
   * Fixed localized Bell field contents.
   * Adapting Bell list contents from system localization.
   * Fixed unlocalized Colour chooser label "Basic colours:" and Font 
chooser initial font sample.
   * Fixed localized Colour chooser label "Basic colours:".
   * Fixed Colour chooser label "Custom colours:" (disappeared on 
refocussing).
   * Added localization of "Error" popup title.
   * Keeping button labels in reactivated message box.

Configuration and Terminal settings:
   * BellTaskbar setting is switchable by escape sequence CSI ?1042h 
(xterm).
   * New BellPopup setting, switchable by escape sequence CSI ?1043h 
(xterm).
   * Revised Bell section in Options menu.
   * New option FontSample.
   * Tweaking Font chooser dialog to widen font sample area.

Other:
   * Fixed window popup (on escape sequence CSI 5t).
   * Allowed automatic font metrics adjustment to increase row padding.

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

------
Thomas

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[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.

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.

I'm not seeing these problems when I'm working via konsole from a
Linux box.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Thomas Wolff]

Hi Achim,

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.

------
Thomas

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Achim Gratz]

Thomas Wolff writes:
> 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?

Within tmux or more often screen within tmux.  I'll have to try what
happens in plain mintty.

> 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.

No, I don't think it's related to that issue and I haven't changed my
prompt in years.  It's specifically happening only on the last line in
the terminal window with the first character that should wrap onto the
next line and not anywhere else and only when scrolling the window
happens.  If the shell has lost the correct terminal geometry, then it's
wrong on all lines of the terminal, not just the last in my experience.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Brian Inglis]

On 2017-02-05 11:35, Thomas Wolff wrote:
> Hi Achim,
> 
> 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 (shortened lines to 71 
characters to avoid wrap issues and fixed content to match display 
results):

Test of autowrap, mixing control and print characters.
The left/right margins should have letters in order:
M                                                                     m
N
n
O                                                                     o
P                                                                     p
Q                                                                     q
R
r
S                                                                     s
T                                                                     t
U                                                                     u
V
v
W                                                                     w
X                                                                     x
Y                                                                     y
Z
z

Push <RETURN>

Unfortunately most of the test documentation is in the source as tables.

If you find vttest useful, it might be worth adding to the mintty 
package as a test program, where you or others could ask users with 
problems to run specific tests, as xterm does.

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. 

-- 
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Achim Gratz]

Achim Gratz writes:
> Thomas Wolff writes:
>> 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?
>
> Within tmux or more often screen within tmux.  I'll have to try what
> happens in plain mintty.

OK, it's more… interesting than I first thought.  I can reproduce it
when setting up a screen session inside tmux and I might need to be
connected to the screen session via mosh.  It doesn't consistently
happen even then.  I first thought it had something to do with my
setting TERM to xterm-256color, but it happens with screen-256color as
well.  I've had the issue appear when switching the TERM variable to
xterm-256color and it didn't go away when I've reverted to
screen-256color.  I've meanwhile confirmed I get the same problem when
I'm running under screen-256color all the way from the first shell.

> No, I don't think it's related to that issue and I haven't changed my
> prompt in years.  It's specifically happening only on the last line in
> the terminal window with the first character that should wrap onto the
> next line and not anywhere else and only when scrolling the window
> happens.  If the shell has lost the correct terminal geometry, then it's
> wrong on all lines of the terminal, not just the last in my experience.

I can actually provoke this by simply typing in a too long line: when
the last character in the last line gets entered, the terminal opens a
new line below, scrolling the content up one line (and keeping the
status line of the tmux in place on the _real_ last line).  It then
scrolls up another line, repeats the the first character of the prompt
on the original line and appends any further characters entered after
that character.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Thomas Wolff]

Am 06.02.2017 um 20:16 schrieb Achim Gratz:
> Achim Gratz writes:
>> Thomas Wolff writes:
>>> 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?
>> Within tmux or more often screen within tmux.  I'll have to try what
>> happens in plain mintty.
> OK, it's more… interesting than I first thought.  I can reproduce it
> when setting up a screen session inside tmux and I might need to be
> connected to the screen session via mosh.  It doesn't consistently
> happen even then.  I first thought it had something to do with my
> setting TERM to xterm-256color, but it happens with screen-256color as
> well.  I've had the issue appear when switching the TERM variable to
> xterm-256color and it didn't go away when I've reverted to
> screen-256color.  I've meanwhile confirmed I get the same problem when
> I'm running under screen-256color all the way from the first shell.
Why would you want to run screen within tmux?
Anyway, I cannot reproduce the issue, although I used to have strange 
effects with a remote screen or tmux once myself.
I'd either need a reproducible test case (like start a fresh mintty, run 
screen (locally/remotely?), type a certain command etc),
or, likely easier in this case, a screen log that demonstrates the 
effect (mintty -l logfile).
You may also try to toggle wraparound mode; see the mail I'm going to 
write in response to Brian's response.

>> No, I don't think it's related to that issue and I haven't changed my
>> prompt in years.  It's specifically happening only on the last line in
>> the terminal window with the first character that should wrap onto the
>> next line and not anywhere else and only when scrolling the window
>> happens.  If the shell has lost the correct terminal geometry, then it's
>> wrong on all lines of the terminal, not just the last in my experience.
> I can actually provoke this by simply typing in a too long line: when
> the last character in the last line gets entered, the terminal opens a
> new line below, scrolling the content up one line (and keeping the
> status line of the tmux in place on the _real_ last line).  It then
> scrolls up another line, repeats the the first character of the prompt
> on the original line and appends any further characters entered after
> that character.
See above. This might have helped already but it didn't. More precise 
reproduction instructions are needed.
------
Kind regards
Thomas

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Thomas Wolff]

Am 05.02.2017 um 21:36 schrieb Brian Inglis:
> On 2017-02-05 11:35, Thomas Wolff wrote:
>> Hi Achim,
>>
>> 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?
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>
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>
http://invisible-island.net/xterm/xterm.faq.html#vt100_wrapping
VT100 Termcap Entry (CENG 455) 
<http://www.pitt.edu/%7Ejcaretto/text/cleanup/vt100-termcap.html>
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.
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.

------
Thomas

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Doug Henderson]

On 6 February 2017 at 12:46, Thomas Wolff wrote:
> Am 05.02.2017 um 21:36 schrieb Brian Inglis:
>>
>> On 2017-02-05 11:35, Thomas Wolff wrote:
>>>
>>> Hi Achim,
>>>
>>> Am 04.02.2017 um 17:13 schrieb Achim Gratz:
>>>>
>>>> Thomas Wolff writes:
>>>>>
>>>>> I have uploaded mintty 2.7.4 with the following changes:

This may be a whisper from the distant past when some glass ttys moved
the cursor to the next line when you wrote to the last column of a
line, and others did not move the cursor until you wrote the next
character. Or they were different depend the width mode: 80 or 132
characters.

A virtual terminal handler, such as curses, had to know which behavior
would occur on the physical terminal in order to correctly maintain
the virtual terminal cursor position. When you did not know what the
physical terminal would do, you had to avoid writing to the 80th
column, or use safe cursor positioning that would work in either case.

Back in the day, I wrote a full screen editor that was usable with a
luggable glass tty with a 300 baud acoustic modem. Optimizing the data
stream was an extreme priority.

I also enhanced the terminal emulator that came with Plan 9 to more
fully emulate DEC's VT100 family of physical terminals when connected
to various remote mini's and mainframes running full screen apps.

When you don't know the precise behavior of a terminal or terminal
emulator, you must fallback to "safe" defaults. You can't always trust
the TERM variable. If you're lucky, you will get a standard
answer-back, which, in the case of a terminal emulator, may be
faithfully emulated.

Programs like screen and tmux throw themselves into the middle of this muddle.

HTH or at least entertained
Doug

-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[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

> 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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Thomas Wolff]

[-- Attachment #1: Type: text/plain, Size: 6063 bytes --]

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.
------
Thomas

>
>> VT100 Termcap Entry (CENG 455)
>> http://www.pitt.edu/%7Ejcaretto/text/cleanup/vt100-termcap.html

[-- Attachment #2: vt-wraparound --]
[-- Type: application/octet-stream, Size: 1343 bytes --]

[-- Attachment #3: Type: text/plain, Size: 219 bytes --]


--
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

diagnostic character info (Re: [ANNOUNCEMENT] Updated: mintty 2.7.4)

[Thomas Wolff]

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:
>>> 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, ... it might be a nice feature.
> Displaying the character set codes passed to the console.
I'm preparing such an option. However, I plan to indicate the actual 
Unicode characters effective on the cursor position (i.e. not the 
multi-byte encoded characters).

> ...
> . Unicode BMP Fallback Font displays each character in the BMP as hex
> within a square box:
I don't see much purpose in using such a font because you won't easily 
recognise your actual text anymore.
But if you want that for debugging, there's no specific mintty support 
necessary for it.

Cheers
Thomas

> 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.

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Brian Inglis]

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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Achim Gratz]

Thomas Wolff writes:
> 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.

That will take a while.  I'll have to set up something at home
specifically with the goal of reproducing the error.  At the moment it
looks like some sort of race between decisions made at different levels
of the stack mintty / tmux / mosh / screen since so far I've not been
able to reproduce if I take out one of these.

Are earlier versions of mintty, specifically the last versions of the
2.6 series, still available somewhere?  I'm almost certain that these
sort of things didn't happen before October or November last year.  Of
course it might have been another update of the other programs involved
as well.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Thomas Wolff]

Am 08.02.2017 um 19:34 schrieb Achim Gratz:
> Thomas Wolff writes:
>> 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.
> That will take a while.  I'll have to set up something at home
> specifically with the goal of reproducing the error.  At the moment it
> looks like some sort of race between decisions made at different levels
> of the stack mintty / tmux / mosh / screen since so far I've not been
> able to reproduce if I take out one of these.
>
> Are earlier versions of mintty, specifically the last versions of the
> 2.6 series, still available somewhere?
You can download older sources from 
https://github.com/mintty/mintty/releases and build them yourself.
Older versions may need some source or makefile tweaks to compile, I 
should publish my notes about this.

> I'm almost certain that these
> sort of things didn't happen before October or November last year.  Of
> course it might have been another update of the other programs involved
> as well.
I would suspect the latter as there have not been recent changes (since 
2.2.1) in the actual terminal emulation.

Actually I have found a bug in the combination of auto wraparound mode 
with scrolling region margins and origin mode.
Once fixed, that could even affect the issue, we'll see.

------
Thomas

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Thomas Wolff]

Am 08.02.2017 um 23:51 schrieb Thomas Wolff:
> Am 08.02.2017 um 19:34 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>> 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.
>> That will take a while.  I'll have to set up something at home
>> specifically with the goal of reproducing the error.  At the moment it
>> looks like some sort of race between decisions made at different levels
>> of the stack mintty / tmux / mosh / screen since so far I've not been
>> able to reproduce if I take out one of these.
I’ve installed mosh to see what it actually is.
The man page speaks about speculative local echo which sounds like 
asking for trouble...

Anyway, I could reproduce effects as you described with
mintty – tmux – mosh localhost (no additional screen needed)
And, most interesting for me: the same thing happens in xterm, so it’s 
not a mintty issue :)

> Actually I have found a bug in the combination of auto wraparound mode 
> with scrolling region margins and origin mode.
> Once fixed, that could even affect the issue, we'll see.
The supposed bug mentioned before wasn’t related to scrolling regions.
Instead, I’ve tried to mimick xterm in some obscure border cases, and 
now the vttest case 1 page 3 passes as well.

------
Thomas

--
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

Re: diagnostic character info (Re: [ANNOUNCEMENT] Updated: mintty 2.7.4)

[Thomas Wolff]

Am 07.02.2017 um 22:00 schrieb Thomas Wolff:
> 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:
>>>> 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, ... it might be a nice feature.
>> Displaying the character set codes passed to the console.
> I'm preparing such an option. However, I plan to indicate the actual 
> Unicode characters effective on the cursor position (i.e. not the 
> multi-byte encoded characters).
Character information display is available in the current repository 
version.
------
Thomas

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Achim Gratz]

Thomas Wolff writes:
> The man page speaks about speculative local echo which sounds like
> asking for trouble...

It is indispensable when you have a long-latency link.

> Anyway, I could reproduce effects as you described with
> mintty – tmux – mosh localhost (no additional screen needed)
> And, most interesting for me: the same thing happens in xterm, so it’s
> not a mintty issue :)

OK, so that saves me the bother of trying to reproduce it at home
because you already have.  Do you maybe have a workaround, otherwise
I'll have to check if a mosh or tmux update has triggered it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Thomas Wolff]

Am 09.02.2017 um 20:41 schrieb Achim Gratz:
> Thomas Wolff writes:
>> The man page speaks about speculative local echo which sounds like
>> asking for trouble...
> It is indispensable when you have a long-latency link.
>
>> Anyway, I could reproduce effects as you described with
>> mintty – tmux – mosh localhost (no additional screen needed)
>> And, most interesting for me: the same thing happens in xterm, so it’s
>> not a mintty issue :)
> OK, so that saves me the bother of trying to reproduce it at home
> because you already have.  Do you maybe have a workaround, otherwise
> I'll have to check if a mosh or tmux update has triggered it.
Both mosh and tmux try to fiddle around the worries of wraparound mode 
with their own tricky handling, as can be seen by the escape sequences 
in the logfiles if I run only one of them at a time, tmux considerably 
more than mosh.
It's not surprising that this interferes with each other.
------
Thomas

--
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