--nextPart1367753.2KMlm2VpW9
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello.

This is possibly off-topic, but since it involves a full upgrade, perhaps=20
someone here has been trhough this problem and fixed it properly.  I alread=
y=20
did some googling about it, but I didn't find any relevant information (may=
be=20
I chose bad keywords?).

I did a full upgrade of the base system, pkgsrc and X11 (using Xorg from=20
pkgsrc), and noticed that it is almost impossible to work with vi or vim (o=
ur=20
in-tree vi is worse) in a screen (pkgsrc/misc/screen) window in xterm (or=20
KDE's konsole, but I believe any xterm-like program will fail, too): after=
=20
pressing ESC to exit insert mode, the next keystroke causes it to return to=
=20
insert mode and the character (or garbage, if it is an arrow key, for=20
example) to be inserted in the text.

In vim, the problem sometimes does not happen if I wait a "long" time (abou=
t=20
three seconds) between ESC and the next keystroke.  With our native vi, it=
=20
does not matter how much I wait after pressing ESC: the next key will cause=
=20
it to go back to insert mode and gets in the text, unless I press ESC=20
multiple times, which causes the cursor to go left a column at time, until =
it=20
reaches the first column, when the next key does what it is supposed to do.

I did some experiments, too.  vi/vim work OK in xterm if I don't use screen=
=2E =20
I logged in the console of a machine with 3.0+XFree86+screen 4.0.2 and made=
=20
sure that vi/vim worked properly in it, then I ran ssh to the affected=20
machine, and the wierd behaviour happened in the ssh channel (ssh in the=20
local xterm window, not remote xterm through ssh tunnel to the affected=20
machine).  Back to the affected machine, I exited X11 and ran the test in=20
wscons, without problems.  Then I restarted X11, opened a xterm window, and=
=20
changed the terminal type to vt100 before launching screen, and everything=
=20
ran OK.  I opened another xterm window and, keeping terminal type as xterm,=
=20
ran ssh to the 3.0- machine, and nothing went wrong.  I also copied the=20
screen binary from the 3.0- machine and ran it, and it misbehaved too. =20
Lastly, I comapred termcap entries for xterm in both machines, finding one=
=20
single difference in the 'kB' capability, that didn't exist in 3.0, but=20
removing it in the new system didn't seem to work.

I vaguely remeber having had a similar problem with Fedora 6 in a machine a=
t=20
work, so this may not be a NetBSD-only problem.  Has anyone seem anything=20
similar, and can share the solution?

=2D-=20
	Pappires

=2E.. Qui habet aurem audiat quid Spiritus dicat ecclesiis.

--nextPart1367753.2KMlm2VpW9
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQBGA0UKA7Y2QNkoMq8RArKdAJ9aCMcxq4lSop9R/HK962LjwFibKwCgqi81
0YVU2inoxaxbNpHO8lp9JFo=
=DfHa
-----END PGP SIGNATURE-----

--nextPart1367753.2KMlm2VpW9--