curses

[zben at umd5.UUCP]

In article <2403 at pegasus.UUCP> hansen at pegasus.UUCP (60545451-Tony L. Hansen;LZ 3B-315;6243) writes:
>In article <571 at umd5.UUCP> zben at 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 at umd2.ARPA