peter@ficc.uu.net (Peter da Silva) (04/09/90)
In article <12538@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > Wrong. Mark Horton was motivated to develop terminfo primarily because > the structure of termcap was too restrictive for many attributes of > modern terminals. Problems included: > - 1024 characters are not enough for a complete description That limit could have been changed without doing a complete redesign. An evolutionary change. > - parsing the huge database was taking too long That's an implementation detail. Set up an index file, or use the TERMCAP environment variable (which is even more flexible). An evolutionary change. > - some cursor positioning sequences require programmable logic That could have been fixed by updating "cm" or adding a "cp". Again, an evolutionary change. > - some capabilities require more than two parameters Again, an evolutionary change. Create a "tgoto3", or a "tgotof". > - the 2-letter capability names are getting quite strained My own implementation of termcap for CP/M didn't have this limitation. This could have been an evolutionary change. > No, when multiple agents try to add their own termcap extensions, they > usually end up stepping on each other. This is a problem whenever people share a namespace. But it's better than not having the option at all. Better to just expand the namespace. > >Recently I used this to good advantage to add a "meta-key" field for > >the use of Emacs here... > Of course what you should have done is use the official termcap > capability for this. Which is not documented in our manual. And if I needed a new capability not in our terminfo I'd be out of luck. Besides, *your* meta_off and meta_on fields (which I just found in our System V manual) don't serve the purpose of the meta_prefix entry I need. Both sets of terminals we have here have a meta-key, on the TVI-950 it's called "func" and acts like a shift key, sending "^A?^M" (Where ? is the key hit while FUNC is depressed). On the AT keyboards it's called ALT and sends "^[n?" (Again, ? is the key hit while ALT is depressed). How do I support that in terminfo? In termcap I just defined a "KM" string that used a percent-sign to stand for the special character. > >Termcap could have been updated with all the features and performance > >advantages of terminfo, and without confusing the world by creating t[w]o > >partially-compatible standards. > The database parsing issue is the one thing I don't see how you could > fix using compatible extensions to termcap. Set up an index file, that you rehash whenever you change it. This is a solved problem. -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ v
martin@mwtech.UUCP (Martin Weitzel) (04/10/90)
In article <OHT2AIAxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <12538@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: [controverse arguments about TERMINFO and TERMCAP] Just to add some of my experiences with TERMCAP here ... One of our major german computer manufacturer, who pushed UNIX (alias SINIX) into the german small systems market some years ago, used TERMCAP in the following way: For nearly every software product that was available for their UNIX-variant, there was a separate entry in the TERMCAP-file. This was necessary, because the standard capabilities were not sufficient (and IMHO also not well understood). It doesn't hurt them too much, because they only suplied a certain (self manufactured) terminal type. Of course, those customers who wanted to connect other terminal hardware now had to update a multiple of TERMCAP-entries (assume 8 software products, 5 terminal types = 40 TERMCAP-entries!). Most of the new capabilities were undocumented ("why do you want to know the purpose, with our terminals it will work"). Furthermore I am not at all sure if all the software products did it completly in the "right" way. There are some dark corners, especially if you want to handle the wait-time specification at the start of string capabilities right. Some products which I know in more detail took the approach: "Modern terminals don't need wait-times, so why should we care ..." which of course leaves the owners of older equipment standing out in the rain. To draw the bottom line, it has its advantages that TERMINFO is *not* user-extendable. As I would additionally recommend that new programs should allways use curses, I don't see much need for extensions. As Peter mentioned, all individual extensions will create the problem, that the extensions of one manufacturer may collide with the extensions of another one. In the case of TERMINFO there will be extensions from AT&T (eg in SysV R3 they added a few graphic shapes.) If one specific application program needs more individual configuration (eg "logical to physical" key-mapping), it has allways the option to store the information elsewhere. NOTE: This was only *my* opinion, formed by earlier experiences with the way some companies tended to use TERMCAP. In an ideal world, things may have been handled in some other way and other conclusions would apply ... -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
meissner@osf.org (Michael Meissner) (04/10/90)
In article <=5R2.MAxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: | I said: [Termcap is OK, and it's extensible] | | > It's not all that extensiable, it still has the absurd 1024 byte limit | > (and yes I have run into that limit with a vt320 description). | | True, but that's fixable. I've already suggested having a compiled version | (basically a hashed index table into the entries). It is not fixable without fixing all of the old crufty programs that have hardwired 1024 arrays. | > You cannot really add new % operators to the core fields, without | > recompiling all of the termcap utilities. | | On the other hand you can't extend Terminfo at all. And recompiling is | fine if you want to add a new capability that your new program needs | but nobody else cares about. | | Besides, with shared libraries you *can* add new operators without | recompiling or relinking anything. | | > Also, termcap cannot handle really weird terminals, due to the limited | > expression capability of the % syntax. Terminfo can, because it | > provides general reverse polish calculations. | | So add a "cp" to supplement "cm" with a more powerful syntax, and phase | out "cm". Or just add a "%(expression)" form to "cm". And then break all programs which use 'cm' as the specification calls for. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
himacdonald@watdragon.waterloo.edu (Hamish Macdonald) (04/10/90)
>>>>> On 10 Apr 90 14:26:33 GMT, meissner@osf.org (Michael Meissner) said: Michael> In article <=5R2.MAxds13@ficc.uu.net> peter@ficc.uu.net Michael> (Peter da Silva) writes: | I said: [Termcap is OK, and it's extensible] | | > It's not all that extensiable, it still has the absurd 1024 byte limit | > (and yes I have run into that limit with a vt320 description). | | True, but that's fixable. I've already suggested having a compiled version | (basically a hashed index table into the entries). Michael> It is not fixable without fixing all of the old crufty programs that Michael> have hardwired 1024 arrays. Didn't all these 'crufty old programs' have to be 'fixed' to use terminfo rather than termcap?? Seems to me to be the same problem. -- -------------------------------------------------------------------- watmath!watdragon!himacdonald himacdonald@watdragon.waterloo.edu "Guns seldom solve any problems; they merely decide whose will shall prevail for the time being." - Brian Jarvis
peter@ficc.uu.net (Peter da Silva) (04/11/90)
> It is not fixable without fixing all of the old crufty programs that > have hardwired 1024 arrays. Fix the old programs. If you can't, ignore the user's 1024-byte array and malloc your own. > | So add a "cp" to supplement "cm" with a more powerful syntax, and phase > | out "cm". Or just add a "%(expression)" form to "cm". > And then break all programs which use 'cm' as the specification calls > for. Those programs won't work on your Weirdcorp-100 terminal anyway, right? This doesn't differ in any way from the existing situation. -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ v
peter@ficc.uu.net (Peter da Silva) (04/11/90)
One of the other advantages of TERMCAP is that you can do the equivalent of:
putenv("TERMCAP", another_termcap_format_file);
tgetent(buffer, some_name);
stuff = tgetstr("zx", &area);
That is, the routines make up a general property-list type capability
that you can use in all sorts of ways. Consider printcap/modemcap/etc...
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \ 'U`
\_.--._/
vlevy@cbnewsc.ATT.COM (Daniel R. Levy) (04/13/90)
In article <OHT2AIAxds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > > The database parsing issue is the one thing I don't see how you could > > fix using compatible extensions to termcap. > > Set up an index file, that you rehash whenever you change it. This is a > solved problem. And if the sysadmin ever forgets to rehash after a termcap edit... curses programs all of a sudden start going BOOM. Well okay, with a little smarts, the programs could default to reading the termcap the old sequential way, if they find the index file is older than the termcap or if they don't see the expected termcap data when they look using the index data. Or they could start up a setuid program which does the reindexing automatically. Nice thing about using an index file instead of, say, busting up the termcap into lots of little files a la terminfo is that older programs could still use the single termcap file without change... except for ONE issue: > > - the 2-letter capability names are getting quite strained > > My own implementation of termcap for CP/M didn't have this limitation. > This could have been an evolutionary change. Can all older termcap-using programs handle termcaps with more than 2-letter capability names (I mean, safely ignore those capabilities)? Or do they barf? There's the backwards-compatibility issue to consider. Better to make a clearly backwards-incompatible revolutionary change a la terminfo, IMO, than to come up with a system which may or may not support an older application and may cause the older application fall down on you unexpectedly. From what I hear (from the Horse's Mouth, dmr), the current Research UNIX system doesn't support terminfo anyhow. -- Daniel R. Levy >>> God: just say "yes" <<< AT&T Bell Laboratories UNIX(R) mail: att!ttbcad!levy, att!cbnewsc!levy 1000 East Warrenville Rd. Any opinions expressed in the message above are Naperville, Illinois 60566 mine, and not necessarily AT&T's.
kpv@ulysses.att.com (Phong Vo[drew]) (04/14/90)
In article <15074@cbnewsc.ATT.COM>, levy@cbnewsc.ATT.COM (Daniel R. Levy) writes: > In article <OHT2AIAxds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > > > The database parsing issue is the one thing I don't see how you could > > > fix using compatible extensions to termcap. > > > > Set up an index file, that you rehash whenever you change it. This is a > > solved problem. > > And if the sysadmin ever forgets to rehash after a termcap edit... > curses programs all of a sudden start going BOOM... > Yes, this can be a bit troublesome. The last time I looked, the largest termcap file we have is about 2700 lines and ~130K. This can be read fairly quickly. The main problem with the tgetstr, tgetnum crowd is that they go thru an entry linearly for each capability. This means quadratic time for parsing an entire entry. This is where all the time is spent for the termcap accessing functions. Assuming that all the capability names are known in advance, it's not too hard to automatically generate these functions so that the parsing time for an entry is linear in its length. This is the method used in my personal version of curses which can also support both termcap and terminfo simultaneously. It is really no big deal to write code that knows about both database formats. It certainly obviates the need to argue the merits of either.
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/14/90)
In article <15074@cbnewsc.ATT.COM> levy@cbnewsc.ATT.COM (Daniel R. Levy) writes: >From what I hear (from the Horse's Mouth, dmr), the current Research UNIX >system doesn't support terminfo anyhow. I'm not sure what that's supposed to prove. Research UNIX inherited 4BSD stuff, which didn't include terminfo, and presumably nobody has bothered to import terminfo from System V. Perhaps that's because the "sam" editor uses neither terminfo NOR termcap.