matt@srs.UUCP (Matt Goheen) (01/16/88)
I just put up "rn" (finally) yesterday and it appears to have a small but annoying bug in the built-in pager. Each time rn prompts for input, it outputs 1 or 2 too few spaces such that columns don't line up properly. This happens on my terminal (a Qume QVT-109), on our Sun consoles and when running the "screen" program on either. It appears that rn is putting out an extra ESCAPE character after it exits stand-out mode on the Qume. At first I thought that the terminal might be doing something strange because of that, but it turns out that rn really puts out a variable number of spaces. Any answers? Sorry if this has been brought up before, but as I said, I just got rn a couple days ago. Version is 4.3, patchlevel 40 (is this up-to-date?). Thanks, -- -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- - UUCP: {allegra,rutgers,ames}!rochester!srs!matt Matt Goheen - - "Stay out of trouble." S.R. Systems - -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
amos@taux01.UUCP (01/17/88)
I have also encountered this problem, and even wrote to Larry Wall about it (and got no answer because he has just moved to jpl). Anyway, after making a few tests I found the culprit: it's the tty driver! When in -tabs mode, it tries to expand tabs to blanks; it receives from rn something like: <return><esc sequence><tab><more stuff>. The characters in <esc sequence> are counted as printable, but are not displayed; hence the number of blanks to which <tab> expands is too small, and <more stuff> is displayed a space or two to the left of its intended position. The fix: do 'stty tabs' in your .login or .profile, and make sure the hard tabs are set correctly (on BSD-type systems, 'tset' takes care of that). -- Amos Shapir (My other cpu is a NS32532) National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 amos%taux01@nsc.com 34 48 E / 32 10 N
matt@srs.UUCP (Matt Goheen) (01/19/88)
In article <444@taux01.UUCP> amos%taux01@nsc.com (Amos Shapir) writes: >Anyway, after making a few tests I found the culprit: it's the tty driver! > >When in -tabs mode, it tries to expand tabs to blanks; it receives from >rn something like: <return><esc sequence><tab><more stuff>. >The characters in <esc sequence> are counted as printable, but are not >displayed; hence the number of blanks to which <tab> expands is too small, >and <more stuff> is displayed a space or two to the left of its intended >position. > >The fix: do 'stty tabs' in your .login or .profile, and make sure the >hard tabs are set correctly (on BSD-type systems, 'tset' takes care of that). Ahhh yes. Now I remember this bug. We had it in a paging program that we have here. I was able to fix it by making the program spit out a "\r" after emitting the escape codes. This only happened after prompts so the fix worked fine. This same fix should work for rn, I'll give it a try. The 'stty tabs' fix does work, but it seems to screw up a few other things a bit. 'rn' almost works as is, except that rn prints out the "ce" string just before it continues after a prompt (with the actual text). Putting in an extra carriage return should solve the problem and not create any more. Does this happen on other systems other than Suns? Seems like it would have to... -- -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- - UUCP: {allegra,rutgers,ames}!rochester!srs!matt Matt Goheen - - "Stay out of trouble." S.R. Systems - -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
matt@srs.UUCP (Matt Goheen) (01/19/88)
In article <556@srs.UUCP> matt@srs.UUCP (I) write: >In article <444@taux01.UUCP> amos%taux01@nsc.com (Amos Shapir) writes: >>Anyway, after making a few tests I found the culprit: it's the tty driver! >> >>When in -tabs mode, it tries to expand tabs to blanks; it receives from > >'rn' almost works as is, except that rn prints out the "ce" string just >before it continues after a prompt (with the actual text). Putting in an >extra carriage return should solve the problem and not create any more. This works fine. There are two files that need to be touched. One is "art.c" and the other is "term.c". Basically, every time you see a "erase_eol()" line, add a line following it "carriage_return()". There are about six places this occurs. Since the line preceding the "erase_eol()" is always a "carriage_return()" anyway, you're pretty much assured that this won't create any problems. As far as I can tell, there is no way to fix this in the terminal driver unless you add termcap support in the driver (hah!) since that is where the terminal specific escape codes reside... -- -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- - UUCP: {allegra,rutgers,ames}!rochester!srs!matt Matt Goheen - - "Stay out of trouble." S.R. Systems - -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-