jba@gorm.ruc.dk (Jan B.Andersen) (01/23/91)
The terminal (a Data General D211) emulates a limited ANSI-terminal,
but unfortunately the designers have decided to 'set' the Line Feed
New Line mode.
When redrawing the screen in vi, a small text like:
main() {
int a;
}
curses assumes it is save just to output the sequence
"<CLEAR> main() { <LF> int a; <CR> <LF> }",
which unfortunately shows up as:
main() {
int a
}
Is there anyway I can tell curses not to thrust LF only doing a LINEFEED
on this terminal?
I have also noticed some incorrect behavior in curses. When scrolling, it
don't move the cursor to the bottom-left corner before emitting the 'ind'
string, it will usually just go to the bottom line before using 'ind',
again assumming the cursor to be in the same column. Disabling 'cub', 'cud',
'cuf' and 'cuu' somehow prevents this from happening.
This is on a Sun4 running SunOS 4.1 with the following terminfo:
d200-ansi|dasher-ansi|Data General DASHER 200 in limited ANSI mode,
am, xon,
cols#80, lines#24,
bel=^G,
cr=\r, nel=\l,
ind=\l,
.cub=\E[%p1%dD, .cub1=\b,
.cud=\E[%p1%dB, .cud1=\n, .cuf=\E[%p1%dC, .cuf1=\E[C,
.cuu=\E[%p1%dA, .cuu1=\E[A,
cup=\E[%i%p1%d;%p2%dH,
home=\E[H,
clear=\E[H\E[J,
ed=\E[J, el=\E[K,
kcub1=\E[D, kcud1=\E[B,
kcuf1=\E[C, kcuu1=\E[A,
khome=\E[H, kbs=\b,
blink=\E[5m,
sgr=\E[%?%p1%t7;%;%?%p2%t4;%;%?%p3%t7;%;%?%p4%t5;%;%?%p6%t1;%;m,
sgr0=\E[0m, smso=\E[7m, smul=\E[4m, rev=\E[7m,
rmso=\E[m, rmul=\E[m,
is2=\036F@,
.rs2=\E[<3l,gwyn@smoke.brl.mil (Doug Gwyn) (01/24/91)
In article <1991Jan23.131741.23026@gorm.ruc.dk> jba@gorm.ruc.dk (Jan B.Andersen) writes: >Is there anyway I can tell curses not to thrust LF only doing a LINEFEED >on this terminal? Yes, you need to use a terminfo/termcap description that doesn't specify that "cursor down one line" can be achieved by transmitting a linefeed character.
jba@gorm.ruc.dk (Jan B.Andersen) (01/24/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >Yes, you need to use a terminfo/termcap description that doesn't specify >that "cursor down one line" can be achieved by transmitting a linefeed >character. I have disabled both "cud" and "cud1" in the terminfo description without any luck. It seems to me that no matter what I do, curses will always use the LF at the end of each text line to move the cursor down to the next line. Can anyone tell me exactly what happens when curses "redraws" the screen? Is it doing a "cursor home", "clear screen", "print #LINES lines", using the EOL-LF to move into the next line?
wieland@ea.ecn.purdue.edu (Jeffrey J Wieland) (01/25/91)
In article <1991Jan23.131741.23026@gorm.ruc.dk> jba@gorm.ruc.dk (Jan B.Andersen) writes: >The terminal (a Data General D211) emulates a limited ANSI-terminal, >but unfortunately the designers have decided to 'set' the Line Feed >New Line mode. Since your dg d211 implements it, try using the ANSI sequence to move down a line, \E[B, for cud1. I suspect your problem go in vi will go away. >d200-ansi|dasher-ansi|Data General DASHER 200 in limited ANSI mode, > cr=\r, nel=\l, > ind=\l, What does \l mean? I can't find it in the terminfo man entry. If your terminal supports it, try setting ind=\ED. For our AT&T 630 terminals, we have nel=\r\n also. It seems to work fine on our Suns, IBM RS/6000, AT&T 3B1's and 3B2's, etc. -- Jeff Wieland wieland@ecn.purdue.edu
gwyn@smoke.brl.mil (Doug Gwyn) (01/26/91)
In article <1991Jan24.113121.29126@gorm.ruc.dk> jba@gorm.ruc.dk (Jan B.Andersen) writes: >I have disabled both "cud" and "cud1" in the terminfo description without >any luck. It seems to me that no matter what I do, curses will always >use the LF at the end of each text line to move the cursor down to the >next line. Can anyone tell me exactly what happens when curses "redraws" the >screen? Is it doing a "cursor home", "clear screen", "print #LINES lines", >using the EOL-LF to move into the next line? Here is a cute technique for finding out exactly what the application is doing: Prepare a termcap/terminfo description similar to the following, using EXACTLY the set of capabilities that is specified for the TERM type that you have been experiencing problems with: # Debugging entry -- all printing characters D1|debug|debugging entry:\ :ae=<ae>:AL=<AL%d>:al=<al>:am:as=<as>:bl=<bl>:bt=<bt>:bw:CC=<CC>:\ :cd=<cd>:ce=<ce>:ch=<ch%d>:cl=<cl>:cm=<cm%d,%d>:co#80:cr=<cr>:\ :cs=<cs%d,%d>:ct=<ct>:cv=<cv%d>:da:db:DC=<DC%d>:dc=<dc>:DL=<DL%d>:\ :dl=<dl>:dm=<dm>:DO=<DO%d>:do=<do>:ds=<ds>:ec=<ec%d>:ed=<ed>:ei=<ei>:\ :es:fs=<fs>:ho=<ho>:hs:IC=<IC%d>:ic=<ic>:im=<im>:ip=<ip>:is=<is>:\ :it#8:K1=\E1:K2=\E2:K3=\E3:K4=\E4:K5=\E5:k0=\Ef0:k1=\Ef1:kA=\EA:\ :ka=\Ea:kb=\Eb:kC=\EC:kD=\ED:kd=\Ed:kE=\EE:ke=<ke>:kF=\EF:kH=\EH:\ :kh=\Eh:kI=\EI:kL=\EL:kl=\El:kM=\EM:km:kN=\EN:kP=\EP:kR=\ER:kr=\Er:\ :kS=\ES:ks=<ks>:kT=\ET:kt=\Et:ku=\Eu:l0=F0:l1=F1:LE=<LE%d>:le=<le>:\ :li#24:ll=<ll>:mb=<mb>:md=<md>:me=<me>:mh=<mh>:mi:mk=<mk>:mm=<mm>:\ :mo=<mo>:mp=<mp>:mr=<mr>:ms=<ms>:nd=<nd>:nw=<nw>:pb#4800:pc=<pc>:\ :pf=<pf>:pO=<pO%d>:po=<po>:ps=<ps>:rc=<rc>:RI=<RI%d>:rp=<rp%.%d>:\ :rs=<rs>:sc=<sc>:se=<se>:SF=<SF%d>:sf=<sf>:so=<so>:SR=<SR%d>:sr=<sr>:\ :st=<st>:ta=<ta>:te=<te>:ti=<ti>:uc=<uc>:ue=<ue>:UP=<UP%d>:up=<up>:\ :us=<us>:vb=<vb>:ve=<ve>:vi=<vi>:vs=<vs>:vt#3:ws#80: Then set TERM to "debug" and run the application through its paces. Instead of invisible control actions, you should now get a printable representation of every output capability being used. If you still see an actual newline being output, the application is at fault.