vim and gnu screens scrolling problem

[jared...@yahoo.com]

For some strange reason, when using gnu screens with vim, the
scrolling doesn't work properly, leaving text remnants on the status
line. Worse yet, when I exit, scrolling functionality completely
disappears and I am able to see only one line of the screen. I've
completely removed my .vimrc file and the results persist. I've tried
many different variants of .screenrc to try to get it working
correctly, and did manage to find a hack which works by forcing an
error code in the "hardstatus" line (which in Putty, is the terminal
window title), however, I was wondering if anybody knows the correct
way to make this work.

Here is a copy of my .screenrc file:

shelltitle $HOST
caption always "[%t]:
%n %D %M %d %c"
escape `` # use backtick instead of cntrl-a
deflogin off
startup_message off # Turn off the splash screen
bindkey -d screen # [INS] - create a new screen
bindkey -d next # [PGDN] - to go to next screen
bindkey -d prev # [PGUP] - to go to previous screen
bindkey -d number # [HOME] - display
#
# make the backspace key send a backspace (CTRL-H:)
bindkey -d stuff ^H

# special xterm hardstatus: use the window title.
defhstatus "[^Et]: ^E | $DATE"
termcapinfo xterm 'hs:ts=\E]2;:fs=\007:ds=\E]2;[^Et]: ^E $DATE\007'


hardstatus always
# this is an intentionally bad command to give an error message in
the title window
# but it's the only way I could get vim to function as expected


# Window numbering starts at 1
bind c screen 1
# (Doesn't work, not sure why)

# for vim
# vim: syntax=screen
# (No noticeable effect here, either)

# startup sessions

screen -t host1

hardstatus always
#Again, I am forced to create a titlebar error

screen -t host2 ssh host2

Also, I'd like for the session numbering to start at 1, which doesn't
happen, regardless of how I try to force it (e.g. screen -t host 1).

Any help would be greatly appreciated. Thanks in advance.

[Matrix Mole]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jared...@yahoo.com wrote:
| For some strange reason, when using gnu screens with vim, the
| scrolling doesn't work properly, leaving text remnants on the status
| line. Worse yet, when I exit, scrolling functionality completely
| disappears and I am able to see only one line of the screen. I've
| completely removed my .vimrc file and the results persist. I've tried
| many different variants of .screenrc to try to get it working
| correctly, and did manage to find a hack which works by forcing an
| error code in the "hardstatus" line (which in Putty, is the terminal
| window title), however, I was wondering if anybody knows the correct
| way to make this work.

It might have nothing to do with .screenrc and/or .vimrc settings at
all. I've noticed when using screen that the TERM variable is initially
set to 'screen' (even with tying to set the TERM variable in the
.screenrc file). This may be what's causing a lot of your problems. Open
up your screen session, and check the output of 'echo $TERM' and see
what it reports. You can easily change it with 'export TERM=xterm-color'
or whatever TERM variable you want. You might be able to edit your
termcap entries to set screen termcap to report as xterm-color, I know
that my gentoo system has a terminfo for screen already setup, but the
screen TERM variable causes all manner of havoc when I ssh over to my
slackware box that doesn't have a screen termcap entry.

Also, did you realize you had 'hardstatus always' listed twice in your
.screenrc file?

Matrix Mole
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIdJvNtosHRPp48MRAuW2AKCHIjdJ9PSfhXwn114Iduh+5XNOTwCdHIwW
iTRdV+VssVE8dDcOo64u0bc=
=2Tkc
-----END PGP SIGNATURE-----

[jared...@yahoo.com]

> It might have nothing to do with .screenrc and/or .vimrc settings at
> all. I've noticed when using screen that the TERM variable is initially
> set to 'screen' (even with tying to set the TERM variable in the
> .screenrc file). This may be what's causing a lot of your problems. Open
> up your screen session, and check the output of 'echo $TERM' and see
> what it reports. You can easily change it with 'export TERM=xterm-color'
> or whatever TERM variable you want. You might be able to edit your
> termcap entries to set screen termcap to report as xterm-color, I know
> that my gentoo system has a terminfo for screen already setup, but the
> screen TERM variable causes all manner of havoc when I ssh over to my
> slackware box that doesn't have a screen termcap entry.

Unfortunately, I tried forcing the TERM variable to xterm with "tset -
s xterm" and "export TERM=xterm" and got the same poor vim results and
scrollback issues.
However, a terminal mismatch was also my first impression and I have
seen that happen before, but usually simply exporting the TERM
variable is sufficient. However, in this case neither exporting the
TERM variable nor the forced tset had the desired effect.

>
> Also, did you realize you had 'hardstatus always' listed twice in your
> .screenrc file?
>

Yes, this was intentional and is my way of hacking around the
problem. "hardstatus always" generates a usage syntax error briefly
in the title bar, then it returns to the title bar hardstatus I had
specified via "defhstatus "[^Et]: ^E | $DATE". This is just a really
terrible way of doing things and I'd like to know how other people
have correctly fixed the problem.

> Matrix Mole
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)

> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org

[Matrix Mole]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jared...@yahoo.com wrote:
| Unfortunately, I tried forcing the TERM variable to xterm with "tset -
| s xterm" and "export TERM=xterm" and got the same poor vim results and
| scrollback issues.
| However, a terminal mismatch was also my first impression and I have
| seen that happen before, but usually simply exporting the TERM
| variable is sufficient. However, in this case neither exporting the
| TERM variable nor the forced tset had the desired effect.

If it's not the TERM variable, I honestly don't know what it might be.
If this issue only happens to vim inside of screen, I'd say it has to be
something to do with screen directly, but not certain where.

One other thing to check, what program are you using to attach to the
screen session (xterm, rxvt, Eterm, aterm, putty, etc)? I would
recommend trying a different terminal program and attach to screen with
it. If you get the same behavior, then it'd help narrow down the problem
between vim and screen, if not, then maybe it's something with the
particular terminal program you're using.

Beyond that, I honestly have no idea where next to go. Unfortunately,
there isn't much in the way of support for screen on the web, the one
mailing list I did find for it (a yahoo group) was disbanded a good 3-4
years ago IIRC.

Matrix Mole
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIeqyNtosHRPp48MRAhkMAJ954nprjc4ES23zALJLZwb2O9ykRgCeIcU0
Vetjli0FRWPMcN9g3tTijyw=
=3KF6
-----END PGP SIGNATURE-----

[Gary Johnson]

On 2008-05-07, Matrix Mole <mat...@gmail.com> wrote:

> jared...@yahoo.com wrote:
> | Unfortunately, I tried forcing the TERM variable to xterm with "tset -
> | s xterm" and "export TERM=xterm" and got the same poor vim results and
> | scrollback issues.
> | However, a terminal mismatch was also my first impression and I have
> | seen that happen before, but usually simply exporting the TERM
> | variable is sufficient. However, in this case neither exporting the
> | TERM variable nor the forced tset had the desired effect.

Have you checked that $LINES is correct? Check that value in the
shell or execute

:set lines?

within vim. I've had similar problems when for some reason the
number of lines actually in the display and the number of lines vim
thought were in the display got out of sync.

> Beyond that, I honestly have no idea where next to go. Unfortunately,
> there isn't much in the way of support for screen on the web, the one
> mailing list I did find for it (a yahoo group) was disbanded a good 3-4
> years ago IIRC.

Did you go to http://www.gnu.org/software/screen/? That page
mentions two mailing lists: the users list has posts from this
month and the devel list has posts as recent as March.

Regards,
Gary

[jared...@yahoo.com]

I did find an acceptable, though still not perfect, solution to this
question.

When reading this FAQ:
http://www4.informatik.uni-erlangen.de/~jnweiger/screen-faq.html

It explains how your terminal and app settings can get mangled but is
very vague on how to fix them.

See these specific questions for more details:

"Q: Screen gets the terminal size wrong and messes up.
and
Q: Screen messes up the terminal output when I use my favourite
application. Setting the terminal size does not help."

So the problem was as Gary had correctly pointed out that for some
reason, vim uses 24 column lines and gnu screen uses only 23.

I know this by doing as the FAQ had suggested and typing "<Control-
a>i" from within screen and compared it to the "xterm" entry in /etc/
termcap:

xterm|vs100|xterm terminal emulator (X window system):\
:ut:li#24:\

Terrific. Now all I had to do was change how many lines "screen"
wanted to use.

So, I should have been able to do that by simply adding this line in
my .screenrc:

termcapinfo xterm* li=24

However that didn't work. Then I looked at how many lines Putty had
assigned to my session and noted that it was 24 as well, yet for some
strange reason, gnu-screen insisted on using 23 lines and breaking
vim.

I decided to do 2 things to remedy the problem:

1) Changed the number of lines in my Putty configuration from 24 to
25, banking on the fact that screen would automagically subtract 1
line and then my screen info output would yield the desired 24.
2) Added this line to the top of my .vimrc file:
set lines=24

Now everything worked as expected as gnu screen, Putty, and vim all
agreed on the correct number of lines.
The only remaining frustratable is that I should not have had to
change my Putty config... Surely, there is a way in gnu-screen to set
the number of lines to 24, but try as I might, I was unable to find
it.

At any rate, I hope that helps somebody else who may be watching this
thread.
Thanks again to all for helping me look in the right direction.

[Gary Johnson]

First off, congratulations on your diligence and on finding a
solution that works for you.

That being said, this is a _horrible_ solution! Getting the number
of lines and columns in the terminal emulator window to the
application is something that should Just Work. If it doesn't, then
something in your system or configuration is broken and you should
find and fix it. Otherwise, this problem will continue to plague
you as your solution will break when any part of it is changed. It
will break, for example, if you ever change the size of your PuTTY
window.

When you log in to the remote system, you should be able to execute

echo $LINES $COLUMNS

in the remote shell and see something like this in response:

24 80

If you do, that should be all you need. But then you wouldn't be
having this problem. If you don't see that, try executing this:

eval $(resize)
echo $LINES $COLUMNS

On most systems I've used, that will set $LINES and $COLUMNS
correctly. On some, it doesn't. If that doesn't work, see what you
get when you execute this:

tput lines

If that works, then you can execute these commands:

LINES=$(tput lines)
COLUMNS=$(tput columns)

You should probably also execute

export LINES
export COLUMNS

to make sure that those variables are successfully exported to
children of the current shell.

You should never have to set either of those values manually. There
are ways to obtain those values from the terminal and to propagate
those values to applications. You should really find the link in
your system that's broken and fix it properly.

Regards,
Gary

[sc]

for me it's

tput cols

sc

[Gary Johnson]

On 2008-05-07, sc <toot...@swbell.net> wrote:
> On Wednesday 07 May 2008 16:31, Gary Johnson wrote:

> > LINES=$(tput lines)
> > COLUMNS=$(tput columns)
>
> for me it's
>
> tput cols

Oops. Thanks for catching that.

Regards,
Gary