pedz@smu.UUCP (01/03/85)
Two questions looking for your opionings. Please mail responses to me directly and I will post them. First: I get the general feeling that Berkeley is thinking about implementing (or perhaps has already done so) a virtual termianal system. I am not sure what they want to do but here is what I am thinking about doing. Basically take a termcap and curses type implementation and put them down into the kernel. Instead of making system calls, there would be a set of escape sequences which could be used to position the cursor, add lines, delete lines, insert characters, etc. These commands would be interpreted and then the real sequence of commands would be sent out by the kernels code. You are probably asking "why do this". Well, it would seem to me that it would utilize the physical memory better. If there is more than one program that uses some type of terminal cursor control package running at a particular time, then there is as many copies of the code to do cursor positioning in the memory someplace. There are also many advantages to this type of system. Basically since the code is already there, programmers would be much more likely to go ahead and do the proper things on the screen where in some cases, they simply dont bother. Also, such things as tabs and so forth could always be handeled properly. So the question is, what do you think about putting this much code into the kernel. Obviously this is only intended for computers with large physical memories. Second: I recently wrote a "more" type program with the added feature of being able to move forward and backward through the file. The first few versions of the program simply kept an index of the file and then did seeks when the person wanted to go backwards. The last version I wrote simply keeps all of the lines "in memory". Note that we have a Vax with virtual memory. Thus the question is, which is better: doing random accesses on a disk file or doing random accesses in the virtual memory swap space? Perry convex!smu!pedz pedz@smu (csnet)
zben@umd5.UUCP (01/06/85)
In the context of this, let us consider improvements to the TermCap system. One real inadequacy of TermCap is its less than adequate support for *INPUT* translation. The Unix editors and such finesse the issue by refusing to support terminal capabilities such as arrow keys, built-in insert/delete modes, and other features. From a "User Friendlyness" point of view this is a real loss, although a cogent argument can be made for the current scheme of providing a terminal-independant input language (I,J,K,L, etc in VI, etc). Other issues, such as "what happens when you type backspace in column one?" and "what happens when you type linefeed in row 24?" are finessed by using smart echoing to avoid the need to know. Long before finding out about TermCap I wrote a screen editor for really dumb systems, using a dedicated procedure for each terminal to translate both input and output to a program-specific internal language. It will work on systems that do not provide raw, or even rare terminal access. Right now it works on both Univac 1100 (Exec 8) and IBM 4341 (VM/CMS) systems. To make the scheme work from a TermCap system one would need input translations. There also exists a "TN3270" program that does TelNet into IBM systems from Vaxen. Unfortunately, TermCap does not provide enough for doing this, so the program has its own database of terminal types. An expanded TermCap system could obviate the need for Yet Another Terminal Database.... What say ye? Ben Cranston ...seismo!umcp-cs!umd5!zben zben@umd2.arpa
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/06/85)
> One real inadequacy of TermCap is its less than adequate support for *INPUT* > translation. ?? Termcap already has facilities for defining input sequences (via capabilities whose names start with `k'). Perhaps you have obsolete termcap documentation.
chenr@tilt.FUN (Ray Chen) (01/08/85)
>In the context of this, let us consider improvements to the TermCap system. >One real inadequacy of TermCap is its less than adequate support for *INPUT* >translation. The Unix editors and such finesse the issue by refusing to >support terminal capabilities such as arrow keys, built-in insert/delete modes, >and other features. Untrue. termcap supports these features quite nicely by doing what a database should do, indicate the presence of the features (see ku, kd, kl, kr, im, etc.). What the program decides to do with this information is another story. >From a "User Friendlyness" point of view this is a real >loss, although a cogent argument can be made for the current scheme of >providing a terminal-independant input language (I,J,K,L, etc in VI, etc). >Other issues, such as "what happens when you type backspace in column one?" >and "what happens when you type linefeed in row 24?" are finessed by using >smart echoing to avoid the need to know. So what's the matter with smart echoing? On an IBM 327x terminal you end up wrapped around to column 79 of the next||previous line. >Long before finding out about TermCap I wrote a screen editor for really >dumb systems, using a dedicated procedure for each terminal to translate both >input and output to a program-specific internal language. It will work on >systems that do not provide raw, or even rare terminal access. Right now it >works on both Univac 1100 (Exec 8) and IBM 4341 (VM/CMS) systems. To make >the scheme work from a TermCap system one would need input translations. Sigh. First thing, you want to avoid having code for each terminal. How many terminal types/classes does your editor support? How much code is there? You want to write a single terminal driver, and load the proper terminal codes into the driver at run-time. termcap allows you to do this by giving you common names for the codes and allowing you to read the codes for the terminal type in on program initialization. Second, the reason why vi and other programs like to operate in raw mode is that they like having access to every single character. This lets you execute commands with one keystroke even if the keystroke doesn't send an interrupt to the computer (or a return) to get its attention, which is essentially what function keys on say, 327x terminals do. vi could run in cooked mode and ask the user to hit a <return> after every single-letter command but that would get to be a real pain. Actually, we'll probably end up moving towards having dumb computers and very smart terminals in the future. This will make editing much faster since it will minimize the load on the computer and the i/o over the line but for most of us, that will have to wait until cycles get a little cheaper. Companies that are "ahead of their time" regarding this situation got into them because their computers were so dumb they didn't have a choice. How much does a 327x terminal cost? > There also exists a "TN3270" program that does TelNet into IBM systems from > Vaxen. Unfortunately, TermCap does not provide enough for doing this, so the > program has its own database of terminal types. An expanded TermCap system > could obviate the need for Yet Another Terminal Database.... Sorry, you're many years too late. Ever heard of terminfo? Ray Chen princeton!tilt!chenr
scott@whuxl.UUCP (steve scott) (01/10/85)
> In the context of this, let us consider improvements to the TermCap system. > One real inadequacy of TermCap is its less than adequate support for *INPUT* ... > program has its own database of terminal types. An expanded TermCap system > could obviate the need for Yet Another Terminal Database.... > > What say ye? > > Ben Cranston ...seismo!umcp-cs!umd5!zben zben@umd2.arpa Ben- Try TERMINFO(SYS 5 R 2) Steve Scott --> ..!ihnp4!houxm!whuxl!scott
pedz@smu.UUCP (01/12/85)
The glories and short comings of termcap was not the issue. Rather should such code be put down into the operting system is the question which I posed. So far, the results have been to instead implement shared libraries which is undoubtedly the way to go. The only problem is, shared libraries would be a much bigger problem. Perry