Hi Martin, In my experience with screen and vi I have heard of nothing like you describe, and it indeed sounds like an incompatibility between MSKermit's rendering code and screen's shenanigans. If you are lucky, this might be just a case of screen not understanding the environment it's living in and trying to do things it shouldn't. First make sure that your $TERM environment variable is set to something sensible, such as vt100, or perhaps vt320, as this site suggests - http://www.sorgonet.com/8086/8088_linux_dumb_terminal/ If that doesn't work, you might want to fiddle with the 'term' variable in .screenrc - it is set by default to 'screen', which might not be recognized, and perhaps 'vt100' will be less confusing for vi. If vi works outside of screen, you might want to try to set this variable to the value of your $TERM environment variable. Failing all these, you can try the .screenrc 'termcap', 'terminfo' and 'termcapinfo' vars. These provide low level control of the terminal capabilities and should solve the problem. The full set of commands is in the screen man page section "THE VIRTUAL TERMINAL". When you go over these, don't look for something specific to the first four columns. Most probably this is something to do with the specifics of the low level erasing updating and writing codes. It seems reasonable that four updates will have to take place when moving the cursor one position rightward - one to erase the cursor, one to redraw the character that has been there, one to redraw the cursor at the new position and one for good measure. If screen expects that your terminal needs to move a hardware cursor leftward for each erasing and forward for each writing, it might be that up to four characters from the left your cursor hits a wall and strange things happen, while afterwards it manages to complete its bizarre dance without lasting damage. Good luck, Yair. On Wed, Aug 15, 2007 at 09:30:56PM -0500, Martin McCormick wrote: > When I am in vi, there is a very annoying behavior that > occurs when I use the lower-case l to move the cursor to the > right such as when stepping over part of a line in order to > edit it. As best as I can describe it, here is what happens: > > As one hits l to step over the first 4 characters, my > VT100 emulation which is Kermit, echoes the first character in > the line which is expected. On the second step, however, it > repeats the first character and then echoes the second > character. On the third step, it echoes the first, the second > and then finally the third. On the 4TH step, it hits you with > the first 3 plus the 4TH. This is extremely annoying in some > cases. After the 4TH character, it works perfectly until the end > of that line. > > One thing I noticed is that with older versions of > screen, it used to only be the first 3 line positions that > caused this behavior. > > When looking at .screenrc, I don't see anything obvious > that deals with the first 4 line positions and don't understand > what advantage there would be in this sort of repetitious > behavior. > > If nobody else notices it, it may be something to do > with MSkermit which generally works very well, but does > occasionally throw one a curve when repainting the screen. > > In the over all scheme of things, this is a nuisance > rather than a show-stopper, but I would sure like to fix it if > possible. > > Thanks for any good suggestions. > > Martin McCormick WB5AGZ Stillwater, OK > Systems Engineer > OSU Information Technology Department Network Operations Group > > _______________________________________________ > Blinux-list mailing list > Blinux-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/blinux-list _______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list