bug in 'cs' value of Xterm termcap (was: Updated: screen 4.1.0-20130513-1)

bug in 'cs' value of Xterm termcap (was: Updated: screen 4.1.0-20130513-1)

[matthew patton]

For whatever reason I set my newly installed environment to use 'xterm' mode and ran across this bug.

The archives led me to
http://www.cygwin.com/ml/cygwin/2013-07/msg00029.html
and specifically

# Set the hardstatus prop on gui terms to set the titlebar/icon title
> termcapinfo xterm*|rxvt*|kterm*|Eterm*|cygwin hs:ts=\E]0;:fs=\007:ds=\E]0;\007

and wanted to mention that with both the -1 and -2 releases, even with the 'termcapinfo' override in the above post the hardstatus and caption lines end up 1 line off the bottom IFF $TERM=xterm be it in an honest to goodness X11 xterm or the windows terminal. This causes everything to fail to properly scroll. Once a single screen worth of output is sent, everything just gets put on the last line. This obviously is not a good thing.

However if $TERM is any of 'cygwin', 'xterm-vt220', 'xterm-256color', 'vt100', or 'vt220' it works just fine since the offending 'cs' stanza is never set like below.

termcap  xterm|fptwist hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
terminfo xterm|fptwist hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l

In my ~/.screenrc it was sufficient to use

termcapinfo xterm* cs

to restore correct behavior. Unfortunately I haven't a clue what the various escape sequences mean.

As a side note I think it would be a good idea to wrap all termcap|info lines with single quotes at least for consistency.


--
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: bug in 'cs' value of Xterm termcap (was: Updated: screen 4.1.0-20130513-1)

[Andrew Schulman]

> For whatever reason I set my newly installed environment to use 'xterm' mode and ran across this bug.
> 
> The archives led me to
> http://www.cygwin.com/ml/cygwin/2013-07/msg00029.html
> and specifically
> 
> # Set the hardstatus prop on gui terms to set the titlebar/icon title
> > termcapinfo xterm*|rxvt*|kterm*|Eterm*|cygwin hs:ts=\E]0;:fs=\007:ds=\E]0;\007
> 
> and wanted to mention that with both the -1 and -2 releases, even with the 'termcapinfo' override in the above post the hardstatus and caption lines end up 1 line off the bottom IFF $TERM=xterm be it in an honest to goodness X11 xterm or the windows terminal. This causes everything to fail to properly scroll. Once a single screen worth of output is sent, everything just gets put on the last line. This obviously is not a good thing.
> 
> However if $TERM is any of 'cygwin', 'xterm-vt220', 'xterm-256color', 'vt100', or 'vt220' it works just fine since the offending 'cs' stanza is never set like below.
> 
> termcap  xterm|fptwist hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
> terminfo xterm|fptwist hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l
> 
> In my ~/.screenrc it was sufficient to use
> 
> termcapinfo xterm* cs
> 
> to restore correct behavior. Unfortunately I haven't a clue what the various escape sequences mean.

Matthew, thanks for reporting that.  So far I'm not able to reproduce it.
Normally I have TERM=xterm-256color outside of screen.  I reset it to
TERM=xterm and started a new instance of screen, and although I set the
hardstatus line, I can't find any problems with scrolling.

Does anyone else observe this problem?  What's the proposed solution?
Remove the two lines you cited above?

See http://cygwin.com/ml/cygwin/2013-10/msg00369.html for another recent
screen scrolling issue that I couldn't reproduce.

> As a side note I think it would be a good idea to wrap all termcap|info lines with single quotes at least for consistency.

I also mostly don't have a clue what the escape sequences mean, although
I've looked up a few of them when I had to.  Mostly that's deep terminal
magic, and I don't mess with it, just pass on what comes from upstream or
I'm otherwise told is needed.

Andrew


--
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: bug in 'cs' value of Xterm termcap (was: Updated: screen 4.1.0-20130513-1)

[Thomas Wolff]

Am 27.11.2013 23:14, schrieb matthew patton:
> For whatever reason I set my newly installed environment to use 'xterm' mode and ran across this bug.
>
> The archives led me to
> http://www.cygwin.com/ml/cygwin/2013-07/msg00029.html
> and specifically
>
> # Set the hardstatus prop on gui terms to set the titlebar/icon title
>> termcapinfo xterm*|rxvt*|kterm*|Eterm*|cygwin hs:ts=\E]0;:fs=\007:ds=\E]0;\007
> and wanted to mention that with both the -1 and -2 releases, even with the 'termcapinfo' override in the above post the hardstatus and caption lines end up 1 line off the bottom IFF $TERM=xterm be it in an honest to goodness X11 xterm or the windows terminal. This causes everything to fail to properly scroll. Once a single screen worth of output is sent, everything just gets put on the last line. This obviously is not a good thing.
>
> However if $TERM is any of 'cygwin', 'xterm-vt220', 'xterm-256color', 'vt100', or 'vt220' it works just fine since the offending 'cs' stanza is never set like below.
>
> termcap  xterm|fptwist hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
> terminfo xterm|fptwist hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l
>
> In my ~/.screenrc it was sufficient to use
>
> termcapinfo xterm* cs
>
> to restore correct behavior. Unfortunately I haven't a clue what the various escape sequences mean.

The ts/fs/ds entries are a trick to mimick the window title as a pseudo
"hard status" line. cs is the "scrolling region".
Not understanding your report completely (what is the -1 and -2
releases?), it could be that some application (maybe screen itself?)
uses cs in the wrong way which produces exactly the described effect. I
noticed myself recently that this can happen if cs is assumed to be just
\E[%i%d;%dr without the %p1,%p2 items, which is kind of weird. Anyway,
does it happen in a fresh terminal, then screen, then ls, or did you run
any other applications before the bug occurs?
------
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