jym@anableps.berkeley.edu (Jym Dyer) (08/28/89)
Gotta question for all you termcap gurus out there.
I've got several termcap documents. One is Richard Stallman's excellent
Termcap manual. It tells me that if just inserting a character in insert
mode (IM) is sufficient, there's no need to define insert character (IC).
A DEC manual says that if you do define IC, IM should be defined in the
termcap file as ":im=:".
Is there ever a case where an insert mode won't let you insert without
using an insert character escape sequence? If so, what kind of insert
mode is it?
I'll tell you why I needs to know. I've got code that runs on Unix that
I'm porting to VMS. I've written a version of setterm() for VMS that gets
information from VMS' termtable file and puts it into Curses variables
(IC, IM, etc.). Unfortunately, the termtable entries for DEC terminals
give values for both IC and IM.
Things work if I just ignore one or the other, but I'm not sure it would
work on all terminals. Does anyone know (1) what logic I should be using
if I have both IC and IM, or (2) what terminals need both to insert?
<_Jym_>gwyn@smoke.BRL.MIL (Doug Gwyn) (08/29/89)
In article <1989Aug28.151908.24779@agate.uucp> jym@anableps.berkeley.edu (Jym Dyer) writes: >I've got several termcap documents. One is Richard Stallman's excellent > Termcap manual. It tells me that if just inserting a character in insert > mode (IM) is sufficient, there's no need to define insert character (IC). > A DEC manual says that if you do define IC, IM should be defined in the > termcap file as ":im=:". DEC is wrong. You should specify both im/ei and ic only if the terminal requires both. Of course, specifying an empty string for im/ei results in the same output sequence as doing it right would, but you cause the application to perform more work than necessary. >Is there ever a case where an insert mode won't let you insert without > using an insert character escape sequence? If so, what kind of insert > mode is it? I don't understand the question. There are im/ei-only, ic-only, and im/ei/ic-combined terminal designs in existence. There is also a strange mode of operation in which not all characters on the right-hand part of the line necessarily shift over when a new character is inserted; the "in" capability is intended to deal with those designs. By the way, IM and IC are not the same as im and ic. There is no IM capability, and IC takes a parameter which specifies how many spaces are to be inserted. im, ic, and ei are parameterless. - D A Gwyn, 4.3BSD TERMCAP(4) editor
chris@mimsy.UUCP (Chris Torek) (08/29/89)
In article <1989Aug28.151908.24779@agate.uucp> jym@anableps.berkeley.edu (Jym Dyer) writes: >... Richard Stallman's excellent Termcap manual ... tells me that if >just inserting a character in insert mode (IM) is sufficient, there's >no need to define insert character (IC). This is correct. >A DEC manual says that if you do define IC, IM should be defined in the >termcap file as ":im=:". This is almost correct. (But then, I suppose that should not be surprising, given the authors :-) ) Programs using termcap that want to insert characters are required to: 0. Enter insert mode. This could be the same as delete mode. (There are terminals that make `backspace' delete characters when in `edit' mode.) 1. Send each character surrounded by `ic' and `ip' sequences. That is, if we had `im=X', `ic=Y', and `ip=Z', the sequence to insert four characters (presuming the terminal is not already in insert mode) `abcd' is: XYaZYbZYcZYdZ There is an exception to rule 1 (sort of): if `IC' is defined, it should be sent (with its numeric parameter expanded) before all of the characters to be inserted; the parameter is the number of characters to be inserted. 4BSD vi actually sends IC and ic and ip, I think. If a terminal or terminal emulator has an escape sequence both for `create space for one character' and for `enter insert mode', where the former can be used without the latter, and vice versa, the latter is generally better since long insert sequences will take less text. Vi and emacs both generally believe that insertion is `free', if it can be done at all, so it is best to make it so. After inserting, and before sending normal characters, if insert mode is the same as delete mode, applications must exist insert mode. (Insert mode and delete mode are the same if `im' and `dm' contain the same strings.) Before using cursor motion, if `mi' is not set, the application must exit insert mode. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
chris@mimsy.UUCP (Chris Torek) (08/29/89)
In article <10860@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >... You should specify both im/ei and ic only if the terminal >requires both. This is misleading, because various applications (including vi) decide that a terminal can insert at all by examining `im' without looking at `ic'. If im is set (to anything, including the empty string), the application assumes the terminal is capable of inserting (using the im+IC+ic+ip sequences). If im is not set, the terminal cannot insert, regardless of what is in IC+ic+ip. This is a historical fact, if not a desirable one. I *know* that this is how vi worked in 4.1BSD, because I ripped some code out of it. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jym@anableps.berkeley.edu (Jym Dyer) (08/29/89)
In article <10860@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > DEC is wrong. You should specify both im/ei and ic only if the terminal > requires both. I figured as much. There are lots of termcap entries, however, where people have specified values for ic and put in ":im=:" (and ":ei=:"). I suspect folks do this because they think it's more efficient . . . > By the way, IM and IC are not the same as im and ic. There is no IM > capability, and IC takes a parameter which specifies how many spaces > are to be inserted. The uppercase forms are the curses variables, which correspond to the lowercase capabilities. I'm sorry if this was confusing. It looks to me like DEC should add another flag capability to its termtable, telling whether or not its im-equivalent is sufficient to insert a character (seeing as how they'll undoubtedly keep their ic- equivalent in there as well). <_Jym_>
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/29/89)
In article <19298@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <10860@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >>... You should specify both im/ei and ic only if the terminal >>requires both. >This is misleading, because various applications (including vi) >decide that a terminal can insert at all by examining `im' without >looking at `ic'. Yes, "vi" is coded that way. It's not an error to fail to use a given capability, just an inefficiency. I think all the termcap and terminfo documentation has explicitly stated that the terminal description should include both (im & ic) only if both are required in order to insert a character. "vi" is being lazy. We have other termcap-driven editors around here that do it right. If "vi" is important to you, by all means adjust your terminal description to cater to its quirks. By the way, I've seen terminals with an "ic" capability where editors were faster if you DIDN'T try to use the "ic" capability.
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (09/01/89)
? - D A Gwyn, 4.3BSD TERMCAP(4) editor Mixing our metaphors aren't we? You can either be: - D A Gwyn, 4.3BSD TERMCAP(5) editor or - D A Gwyn, SVr#v# TERMCAP(4) editor Root Boy Jim and the GNU Bohemians
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/03/89)
In article <20770@adm.BRL.MIL> rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes: >Mixing our metaphors aren't we? You can either be: > - D A Gwyn, 4.3BSD TERMCAP(5) editor >or - D A Gwyn, SVr#v# TERMCAP(4) editor Oh, okay. Choose the former. UNIX System V no longer supports termcap. We continue to use it in our System V emulation on 4BSD, where it is documented under TERMCAP(4). (The native 4BSD version is TERMCAP(5), same except for some extremely minor tweaks.) This "manual section" notation is creaking at the seams, more so since AT&T decided to change theirs midstream. The SVID method (BA_OS etc.) would be good except I think they introduced too many categories.