zben@umd5.UUCP (06/12/85)
I posted flames on the same point. Curses does not support input translation.
Instead, there is a terminal-independant input language for each of the Unix
screen editors. While this setup may have some merit (once you learn it you
can use any available terminal) I have a Pascal screen editor that I run on
Univac 1100 and IBM 370 systems that I would like to also support Unix. This
screen editor operates by catching the keystrokes and updating an incore image
of the current screen. Thus, it MUST know what each keystroke is doing to the
screen...
The amount of brain damage out there in the terminal world is enormous. There
are dozens of cursor addressing schemes, at least three ways of doing carriage
return/line feed, and several ways of insert/delete character/line schemes.
Without knowing any better, I had coded a separate handler procedure for each
different type of terminal. Each is only one or two pages, but at this point
my terminal handlers are bigger than the rest of the editor! I would really
like to move in the direction of terminal capabilities database, but on input
there are some real sticky questions.
For example, when you are in column one, what does a left arrow do? On many
terminals it does nothing, on many more it goes to column 80 of the previous
line, on some it goes to column 80 of the SAME line. What does an up arrow
do on line one? Unix finesses all these questions by refusing to echo the
character in these situations. On mainframes without smart echo, one does not
have that handy copout. Thus, in addition to the simple question of what code
does each key generate, these little quirks must all be represented in the
database.
One additional example. On many terminals, when you do an insert-line
operation, the cursor is left wherever it was. But, on the Heathkit, the
cursor is returned to column one! If you REALLY want to see some brain-
damage, look at the insert mode on the Datamedia 2000/3000 line.
The one example I have seen this done really well on is the Series/1 front
end for IBM 370 machines. This software talks to your cheap ASCII terminal
and presents a 3270 interface to the mainframe. Basically replaces one
brain-damaged terminal with another, i.e. attributes eat a screen posn etc.
Putting in a new terminal requires building a bunch of character lookup
tables, however, and reassembling the program, so its not quite as nice as
being database-based.
--
Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPAhansen@pegasus.UUCP (Tony L. Hansen) (06/28/85)
In article <571@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: >I posted flames on the same point. Curses does not support input translation. The old versions of curses that come withh 4.X BSD did not support input translations. This feature is just one of the many features that were added by Mark Horton to his version of curses when he rewrote it. It is also one of the reasons that he rewrote it. His version is now a part of System Vr2. By saying "keypad(stdscr, TRUE);", all input through stdscr is scanned for escape sequences that match those input keys specified in the terminfo entry. When one is found, an integer is returned whose value is #define'd in <curses.h>. These tokens are named such things as KEY_LEFT and KEY_HOME. Pavel Curtis' public-domain version of Mark Horton's curses also will do this translation. I have no idea how well it works. >I would really >like to move in the direction of terminal capabilities database, but on input >there are some real sticky questions. > >For example, when you are in column one, what does a left arrow do? On many >terminals it does nothing, on many more it goes to column 80 of the previous >line, on some it goes to column 80 of the SAME line. What does an up arrow >do on line one? Unix finesses all these questions by refusing to echo the >character in these situations. On mainframes without smart echo, one does not >have that handy copout. Thus, in addition to the simple question of what code >does each key generate, these little quirks must all be represented in the >database. Define the action to be what you want it to be. As long as pressing the key only causes an escape sequence to be translated, and doesn't really move the cursor locally, you have no problems. If the cursor is only local, then you have no knowledge whatsoever that the cursor got moved. If a sequence is transmitted AND the cursor is moved, then you have a bad terminal. In many cases, terminals of the last two sorts have an escape sequence that will change the action of the function keys. This sequence should be sent out upon startup. In terminfo, such a sequence would be defined by smkx=\Exxx. >One additional example. On many terminals, when you do an insert-line >operation, the cursor is left wherever it was. But, on the Heathkit, the >cursor is returned to column one! If you REALLY want to see some brain- >damage, look at the insert mode on the Datamedia 2000/3000 line. Terminfo and termcap only define insert-line/delete-line when the cursor is in column one. Mark Horton's curses will only use those capabilities when the cursor is in column one. (You get what you pay for.) Tony Hansen hansen@pegasus.ATT.UUCP
zben@umd5.UUCP (07/02/85)
In article <2403@pegasus.UUCP> hansen@pegasus.UUCP (60545451-Tony L. Hansen;LZ 3B-315;6243) writes: >In article <571@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: >>I posted flames on the same point. Curses does not support input translation. > >The old versions of curses that come withh 4.X BSD did not support input >translations. > >This feature is just one of the many features that were added by Mark Horton >to his version of curses when he rewrote it. It is also one of the reasons >that he rewrote it. His version is now a part of System Vr2. > >By saying "keypad(stdscr, TRUE);", all input through stdscr is scanned for >escape sequences that match those input keys specified in the terminfo >entry. When one is found, an integer is returned whose value is #define'd in ><curses.h>. These tokens are named such things as KEY_LEFT and KEY_HOME. > >Pavel Curtis' public-domain version of Mark Horton's curses also will do >this translation. I have no idea how well it works. > This is a welcome and worthwhile extension. I looked at doing this at one time and it looked like the only gore would be back-mapping cursor addressing sequences. Was this done? It would only seem to be useful for terminals that support light pen input by sending in addressing sequences, but I have seen at least one H19 add-on that did exactly this. Not too hard because the CRT controller chip has a light pen input that is unused (grounded). >>I would really >>like to move in the direction of terminal capabilities database, but on input >>there are some real sticky questions. >> >>For example, when you are in column one, what does a left arrow do? On many >>terminals it does nothing, on many more it goes to column 80 of the previous >>line, on some it goes to column 80 of the SAME line. What does an up arrow >>do on line one? Unix finesses all these questions by refusing to echo the >>character in these situations. On mainframes without smart echo, one does not >>have that handy copout. Thus, in addition to the simple question of what code >>does each key generate, these little quirks must all be represented in the >>database. > >Define the action to be what you want it to be. As long as pressing the key >only causes an escape sequence to be translated, and doesn't really move the >cursor locally, you have no problems. If the cursor is only local, then you >have no knowledge whatsoever that the cursor got moved. If a sequence is >transmitted AND the cursor is moved, then you have a bad terminal. In many >cases, terminals of the last two sorts have an escape sequence that will >change the action of the function keys. This sequence should be sent out >upon startup. In terminfo, such a sequence would be defined by smkx=\Exxx. > You missed the quote "on mainframes without smart echoing", specifically a Univac 1100 and an IBM ~370, the input characters are just echoed back, and the terminal, of course, does what it is supposed to do. The problem is, back in the computer, deciding what that was. Unless you want to generate an error and ignore user input up to the next newline (remember we don't get control to do anything until the next newline comes in) you HAVE to know what the terminal did... >>One additional example. On many terminals, when you do an insert-line >>operation, the cursor is left wherever it was. But, on the Heathkit, the >>cursor is returned to column one! If you REALLY want to see some brain- >>damage, look at the insert mode on the Datamedia 2000/3000 line. > >Terminfo and termcap only define insert-line/delete-line when the cursor is >in column one. Mark Horton's curses will only use those capabilities when >the cursor is in column one. > Again, the user could very well hit the insert line button anywhere on the screen. The echo causes the terminal to actually do it, and you have to know what it did in order to continue. -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA
Caruso.Wbst@XEROX.ARPA (08/23/85)
Hello,
I am looking for the Curses sources.
Can anyone point me in the right direction ?
Thanx in advance
Ray Caruso
Webster Research Center
Xerox Corp.
(716) 422 - 7798
or
Caruso.wbst@Xerox.arpa