roger@gtisqr.uucp (Roger Droz) (06/06/90)
What is the "standard" termcap/terminfo description for a vt100 number
pad in "application mode"?
Of course, I know I can map it almost any way I want, but we may some
day purchase an application from a third party (such as WordPerfect)
that depends on the application pad operating in some de-facto
standard way. Also, the cursor arrow keys can operate in "normal" or
"application" mode. How are these typically treated?
A vt100 has function keys PF1 - PF4, so I'm sure one tactic is to
generate more function keys. Also, the vt100 doesn't have keys labeled
next/previous screen, etc. Another tactic would be to give the number
pad keys specific meaning -- something like simulating the IBM PC number pad.
____________
Roger Droz UUCP: uw-beaver!gtisqr!roger
() () Maverick MICRoSystems / Global Technology International
(_______) Mukilteo, WA
( )
| | Disclaimer: "We're all mavericks here:
| | Each of us has our own opinions,
(___) and the company has yet different ones!"gwyn@smoke.BRL.MIL (Doug Gwyn) (06/06/90)
In article <1990Jun6.010609.5797@gtisqr.uucp> roger@gtisqr.UUCP (Roger Droz) writes: >What is the "standard" termcap/terminfo description for a vt100 number >pad in "application mode"? There is no "standard" mapping; indeed, while modern terminfo/termcap supports something like a hundred possible kinds of function key, it does not cover VT100-like adding-machine-labeled keys (distinct from PF keys), other than "ENTER". >Of course, I know I can map it almost any way I want, but we may some >day purchase an application from a third party (such as WordPerfect) >that depends on the application pad operating in some de-facto >standard way. The best tactical approach for such a situation is to define a distinct terminal type to which you set TERM before invoking such an application. (Of course, the termcap/terminfo descriptio for that terminal type would be set up appropriately for the application's expectations.) For example, TERM might be set to "vt100-wp" for WordPerfect. >Also, the cursor arrow keys can operate in "normal" or >"application" mode. How are these typically treated? I found the most useful setting to be the one realized in the termcap description that I've appended to this article. >A vt100 has function keys PF1 - PF4, so I'm sure one tactic is to >generate more function keys. Also, the vt100 doesn't have keys labeled >next/previous screen, etc. Another tactic would be to give the number >pad keys specific meaning -- something like simulating the IBM PC number pad. If you have one of the EDT rubber keypad condoms or some other way to label the keypad keys (even a diagram taped to the right of the screen), then you could do that. However, I've found it more useful to leave the mapping up to the application, using whatever key binding mechanisms are provided. For example, the Jove text editor's ~/.joverc file can map the keypad key sequences into Jove commands: bind-to-key Prefix-2 ^[O bind-to-key Prefix-2 ^[[ bind-to-key previous-line ^XA bind-to-key next-line ^XB bind-to-key forward-char ^XC bind-to-key backward-char ^XD bind-to-key beginning-of-file ^XH bind-to-key write-modified-files ^XM bind-to-key clear-and-redraw ^XP bind-to-key clear-and-redraw ^XQ bind-to-key clear-and-redraw ^XR bind-to-key clear-and-redraw ^XS bind-to-key grow-window ^Xl bind-to-key forward-word ^Xm bind-to-key buffer-position ^Xn bind-to-key next-window ^Xp bind-to-key scroll-up ^Xq bind-to-key scroll-down ^Xr bind-to-key shrink-window ^Xs bind-to-key i-search-reverse ^Xt bind-to-key i-search-forward ^Xu bind-to-key split-current-window ^Xv bind-to-key i-search-reverse ^Xw bind-to-key i-search-forward ^Xx bind-to-key backward-word ^Xy Here is the best generic VT100 termcap entry that I've been able to come up with over the years: # # DEC VT100 with variations for Advanced Video Option and screen width. # The following SET-UP modes are assumed for normal operation: # ANSI_MODE AUTO_XON/XOFF_ON NEWLINE_OFF 80_COLUMNS # WRAP_AROUND_ON # 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_# # 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", "tset", or "tabs" utilities (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! # Thanks to elsie!ado (Arthur David Olson) for numerous improvements. d0|vt100|DEC VT100 with AVO:\ :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:ti=\E[?7l:\ :te=150\E[?7h:ue=\E[m:UP=\E[%dA:up=\EM:us=\E[4m:vt#3:xo:\ :cl=\E[H\E[J:\ :bs:kn#4:pt: dv|vt100-v|DEC VT100 without AVO:\ :ue@:us@:\ :tc=vt100: d8|vt100-w|DEC VT100 with AVO in 132-column mode:\ :co#132:ct=\E[?3h\E[g:\ :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:\ :ct=\E[?3h\E[g:li#14:ll=\E[14H:ue@:us@:\ :tc=vt100-w:
woods@eci386.uucp (Greg A. Woods) (06/07/90)
In article <1990Jun6.010609.5797@gtisqr.uucp> roger@gtisqr.UUCP (Roger Droz) writes: > What is the "standard" termcap/terminfo description for a vt100 number > pad in "application mode"? There isn't one? Actually, I'd suspect the best "standard" could be gleaned by studying several DEC applications (i.e. from VMS or RSTS or RT-11, etc.). Perhaps the TECO layout would suite? :-) I've found the following entry (decompiled with infocmp from the AT&T version supplied with 386/ix) to be quite complete. As you can see, it defines the application mode keypad as more function keys, although the A1,A3,B2,C1,C3 keys are also defined. The terminal I'm on right now is an HDS-2000, and it also works well with the definition below, though it has lots of function keys, and a cursor pad, so I use a different entry most of the time. A quick guess says the extra function keys aren't very useful at all. My only vt100 is used as contty for the machine at home, and as such doesn't get used for any applications, and in general I'm not much of a fan of function keys anyway, especially on terminals without programmable label displays (like the AT&T{6,7}05). As for the vt220, It's got lots of function keys too, so what are you worried about? :-) vt100|vt100-am|dec vt100 (w/advanced video), am, mir, msgr, xenl, xon, cols#80, it#8, lines#24, vt#3, acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>, clear=\E[H\E[J$<50>, cr=\r, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=\b, cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C$<2>, cup=\E[%i%p1%d;%p2%dH$<5>, cuu=\E[%p1%dA, cuu1=\E[A$<2>, ed=\E[J$<50>, el=\E[K$<3>, el1=\E[1K$<3>, enacs=\E(B\E)0, home=\E[H, ht=\t, hts=\EH, ind=\n, ka1=\EOq, ka3=\EOs, kb2=\EOr, kbs=\b, kc1=\EOp, kc3=\EOn, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kent=\EOM, kf0=\EOy, kf1=\EOP, kf10=\EOx, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOt, kf6=\EOu, kf7=\EOv, kf8=\EOl, kf9=\EOw, rc=\E8, rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O, rmkx=\E[?1l\E>, rmso=\E[m$<2>, rmul=\E[m$<2>, rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7, sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t^N%e^O%;, sgr0=\E[m^O$<2>, smacs=^N, smkx=\E[?1h\E=, smso=\E[1;7m$<2>, smul=\E[4m$<2>, tbc=\E[3g, -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA