mdb@bjs.UUCP (Marshall DeBerry) (04/05/88)
Does anyone have a termcap or terminfo (preferred) definition for a Tektronix 4052? If so, could you email or point me in the right direction for obtaining such a description? Thanks in advance. -- Marshall DeBerry Bureau of Justice Statistics Washington DC UUCP: uunet!mimsy!prometheus!yendor!bjs!mdb Phone: 202 724 7774
kim@mcrware.UUCP (Kim Kempf) (01/30/89)
Why is it that the termcap entry for most vt100-style terminals define
the arrow keys as:
:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\
when the keys actually transmit:
:ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:kb=^H:\
Some other termcaps claiming ANSI terminal compatability are defined in this
latter method as expected. I have an application that won't work because of
this problem. Is this some type of special hack that 'vi' uses and other
applications have to know about it, or what? Thanks in advance.
----------------
Kim Kempf, Microware Systems Corporation {sun,uunet}!mcrware!kimgwyn@smoke.BRL.MIL (Doug Gwyn ) (01/31/89)
In article <942@mcrware.UUCP> kim@mcrware.UUCP (Kim Kempf) writes: >Why is it that the termcap entry for most vt100-style terminals define >the arrow keys as: > :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ >when the keys actually transmit: > :ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:kb=^H:\ >Some other termcaps claiming ANSI terminal compatability are defined in this >latter method as expected. I have an application that won't work because of >this problem. Is this some type of special hack that 'vi' uses and other >applications have to know about it, or what? Thanks in advance. The former sequences are transmitted in ANSI (non-VT52) mode when the Cursor Key Mode (DECCKM) is Set and the latter when it is Reset. Before the keypad is used, it is supposed to be initialized by sending the "ks" capability and afterwards it is supposed to be reset by sending the "ke" capability. This is explained in the official termcap manual entry. Termcap descriptions for the VT100 that use the first set of key definitions given above should have the sequence that sets DECCKM. For example, here's the VT100 description we use: # # DEC VT100 # The "vt100" entry supports the Advanced Video Option if present; # however, AVO is not required for correct operation of the "vt100" entry. # The following SET-UP modes are assumed for normal operation: # ANSI_MODE AUTO_XON/XOFF_ON NEWLINE_OFF 80_COLUMNS # Other SET-UP modes may be set for operator convenience or communication # requirements; I recommend # SMOOTH_SCROLL AUTOREPEAT_ON BLOCK_CURSOR MARGIN_BELL_OFF # SHIFTED_3_# WRAP_AROUND_ON # Unless you have a graphics add-on such as Digital Engineering's VT640 # (and even then, whenever it can be arranged!) you should set # INTERLACE_OFF # Hardware tabs are assumed to be set every 8 columns; they can be set up # by the "reset" or "tabs" utility (use vt100-x, 132 columns, for this). # I have included some compatible code in "rs" for the VT640 if you have one. # No delays are specified; use "stty ixon -ixany" to enable DC3/DC1 flow control! d0|vt100|DEC VT100:\ :ae=^O:as=^N:bl=^G:cd=\E[J:ce=\E[K:cm=\E[%i%d;%dH:co#80:cr=^M:\ :cs=\E[%i%d;%dr:ct=\E[3g:DO=\E[%dB:do=^J:ho=\E[H:is=\E<\E)0:it#8:\ :k0=\EOP:k1=\EOQ:k2=\EOR:k3=\EOS:kb=^H:kd=\EOB:ke=\E[?1l\E>:kl=\EOD:\ :kr=\EOC:ks=\E[?1h\E=:ku=\EOA:l0=PF1:l1=PF2:l2=PF3:l3=PF4:LE=\E[%dD:\ :le=^H:li#24:ll=\E[24H:mb=\E[5m:md=\E[1m:me=\E[m:mr=\E[7m:ms:nd=\E[C:\ :nw=\EE:rc=\E8:RI=\E[%dC:\ :rs=^X\E<\E2\E[?9h^]\E^L^X\E[20l\E[?3;9;6l\E[r\E[m\E[q\E(B^O\E)0\E>:\ :sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:ue=\E[m:UP=\E[%dA:\ :up=\EM:us=\E[4m:vt#3:xo:\ :cl=\E[H\E[J:\ :bs:kn#4:pt: d8|vt100-w|DEC VT100 with AVO in 132-column mode:\ :co#132:\ :rs=^X\E<\E2\E[?9h^]\E^L^X\E[20l\E[?9;6l\E[?3h\ \E[r\E[m\E[q\E(B^O\E)0\E>:\ :tc=vt100: d9|vt100-x|DEC VT100 without AVO in 132-column mode:\ :li#14:ll=\E[14H:\ :tc=vt100-w:
mch@ukc.ac.uk (Martin Howe) (02/02/89)
In article <9549@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <942@mcrware.UUCP> kim@mcrware.UUCP (Kim Kempf) writes: >>Why is it that the termcap entry for most vt100-style terminals define >> [termcaps deleted] >>Some other termcaps claiming ANSI terminal compatability are defined in this >>latter method as expected. I have an application that won't work because of >>this problem. Is this some type of special hack that 'vi' uses and other ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>applications have to know about it, or what? Thanks in advance. > >The former sequences are transmitted in ANSI (non-VT52) mode when >the Cursor Key Mode (DECCKM) is Set and the latter when it is Reset. > Here at UKC, if you are using a VT100 in ANSI mode, vi sets DECCKM (see above) when it starts up, and clears DECCKM when it exits. Having termcap defined for =============================== DECCKM permanantly on, and Vi assuming so seems a funny way to do things. Man (5) termcap should tell you how to set up your own private termcap file, if you need to. (BTW, A powered-up or reset VT100 has DECCKM and DECKPAM cleared, and this cannot be changed in SET-UP). Regards -- Martin Howe (This posting is private, and NOT on behalf of UKC)
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/04/89)
In article <42@harrier.ukc.ac.uk> mch@ukc.ac.uk (Martin Howe) writes: >Having termcap defined for DECCKM permanantly on, >and Vi assuming so seems a funny way to do things. I don't think either of those is the case (of course, I don't have access to your particular system; maybe yours really IS hacked up). The termcap specification requires that ks and ke be used to prepare for and conclude using a terminals keypad. The termcap description I posted for the VT100 is consistent with this. Termcap-using programs should follow the spec.