[comp.sources.bugs] rn pager bug

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	-
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-