panon@cheddar.ucs.ubc.ca (Paul-Andre Panon) (07/06/90)
I posted this earlier but I didn't get any replies (possibly because the
Subject: line was completely inappropriate - oops).
When trying to track down some curious behaviour with Screen v2.0a and
vt100 terminals, a friend and I narrowed the problem down to strange
behaviour by the termcap facility as it is called from the ansi.c module.
With the following TERMCAP entry (split up for your benefit):
setenv TERMCAP 'd0|vt100|vt100-am|vt100am:co#80:li#24:do=^J:cl=50\E[;H\E[2J:
sf=5\ED:le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:ce=3\E[K:cd=50\E[J:
so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:
is=\E[1;24r\E[24;1H:rf=/usr/lib/tabset/vt100:
rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:ku=\EOA:kd=\EOB:
kr=\EOC:kl=\EOD:kb=^H:ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:pt:sr=5\EM:vt#3:
xn:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:';
tgetnum("co") and tgetnum("li") return 79 and 23 respectively.
when the TERMCAP entry is modified to contain ... :co#79:li#23: ...
tgetnum() returns the expected values of 79 and 23 for columns and rows.
i.e. When the termcap entry gives a value of 80 by 24, those values somehow
get 1 subtracted from them by the time you can retrieve them through tgetnum().
Could somebody shed a little light on how to tell when you have a 79x23 or an
80x24 screen (other than by duplicating the function of tgetenv() and friends)?
Is this a feature? and, if so, pray tell, what are its origins?
This is while working with BSD termcap on both an Apollo DN3500 running
Domain/OS and a Sun3/2xx(?) running SunOS v4.0.1_Export.
Paul-Andre
P.S. is this a termcap "feature" or should this message be in *.bugs?
--
Paul-Andre_Panon@staff.ucs.ubc.ca or USERPAP1@UBCMTSG
or Paul-Andre_Panon@undergrad.cs.ubc.ca or USERPAP1@mtsg.ubc.ca
Looking for a .signature? "We've already got one. It is ver-ry ni-sce!"samlb@pioneer.arc.nasa.gov (Sam Bassett RCS) (07/06/90)
Many terminals do funny things when the cursor goes into the 80th column of the screen -- like issuing a CR/LF pair even when you don't want one. If this happens, suddenly you get double spacing in your text, which really fouls up your editing. Also, when the cursor goes into column 80 of line 24, terminals often either scroll automatically or put the cursor back to column 1 of line 1 -- which also fouls up editing algorithms. I suspect that, knowing these "features" of common terminals, that the writers of the termcap/curses package punted and returned 79/23 whenever they saw 80/24 -- that way they could assure that the screen would look reasonable under vi/emacs/whatever. Any veteran wizards know different? Sam'l Bassett, Sterling Software @ NASA Ames Research Center, Moffett Field CA 94035 Work: (415) 604-4792; Home: (415) 969-2644 samlb@well.sf.ca.us samlb@ames.arc.nasa.gov <Disclaimer> := 'Sterling doesn't _have_ opinions -- much less NASA!'
guy@auspex.auspex.com (Guy Harris) (07/08/90)
> I suspect that, knowing these "features" of common terminals, >that the writers of the termcap/curses package punted and returned 79/23 >whenever they saw 80/24 -- that way they could assure that the screen >would look reasonable under vi/emacs/whatever. Any veteran wizards know >different? Yup, I know that neither the BSD "termcap" nor the SunOS "termcap" does any such thing. The SunOS "termcap" *does* do a TIOCGSIZE on older releases, and either a TIOCGSIZE or TIOCGWINSZ on later releases, to see whether the tty driver has a notion of the screen size that differs from the notion in the "termcap" entry (for example, the "sun" entry is 34 rows, 80 columns, but a "shelltool", which uses that "termcap" entry, is not necessarily 34x80) and, if it is (i.e., if the sizes are non-zero), it returns the sizes it got from the TIOC call instead. The Apollo "termcap" code may do something similar.