KLH@sri-nic.arpa (Ken Harrenstien) (01/06/88)
Hi. It might help if I explained a little more about how TERMCAP is used, or not used, in ELLE. What Andy said about setting the TERM variable is correct; you must define it to match something in /etc/termcap (and export it). However, because ELLE began (and can still be run on) a V6 11/40 system without TERM or TERMCAP, there are some non-TERMCAP built-in terminal types, with an alternative specification mechanism. To specify a terminal type, you can use the -t switch when invoking ELLE, as in "elle -t h19". If a built-in terminal type is given, either with -t or TERM, ELLE doesn't bother to search for a TERMCAP entry, and the built-in code always takes precedence. The current Minix binary just happens to include "H19", "DM2500", and "DM3025" (not 3500) as built-in terminal types (a DM2500 is what I have, but H19 is/was more common). This was more accident than design; other built-in types exist but were not included in Andy's configuration. While I'm at it, I may as well explain why the built-ins have priority over TERMCAP, and why some people may observe strange redisplay behavior. ELLE tries rather hard, at the expense of some CPU time, to to optimize redisplay by minimizing the number of characters output (including padding). The TERMCAP definitions, while technically correct, sometimes fall short; where built-in code exists, it is normally more efficient, accurate, and reliable. The incompleteness of some TERMCAP definitions is also the major reason why ELLE sometimes appears to use suboptimal redisplay sequences -- there is a subtle assumption that the amount of time required to process terminal escape sequences is the same as the amount of time required to transmit them (including padding). This is a perfectly reasonable assumption for the majority of user terminals, which are at the other end of an asynchronous communications path without flow control. It breaks down when the "terminal" is a screen driven and updated by the operating system itself, which enforces an invisible form of flow control! This is typical of PC Unix implementations, and the TERMCAP definition for the console display often furnishes no padding specifications, thus giving ELLE no way of knowing that a 2-character sequence to delete a line (or char) takes more time than any other 2-character output string. There are two ways of solving this, if anyone cares enough. The first is to use an accurate TERMCAP definition which adequately reflects (in terms of padding) the amount of time each screen operation takes. Since pad characters will simply be ignored by the terminal driver and not actually sent out over a line or anything, the "padding" doesn't hurt. You can fiddle with your definition to get the behavior you want. The second method, which requires sources, is to add the appropriate built-in type (and its operation time values) to the eeterm.c module of ELLE; this is better if accurate pad computation algorithms are difficult to represent in TERMCAP, and for that matter avoids sending any pad chars. This method also opens the possibility of using "direct video", which is very fast; for example, there is a built-in type that uses a special ioctl() call (specific to the Mark Williams COHERENT system) to update the PC screen image directly. Whether Minix needs such an ioctl is debatable, though. --Ken -------