Re: Binding Home and End

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 31, 10:56pm, Frank Terbeck wrote:
}
} Does somebody on the list actually know why such a distinction was made
} at all? And why it would make sense to have a key like `HOME' send
} different bytes depending on which mode is active?

I'm probably propagating a bit of hearsay here, so don't take this as
gospel ... I haven't been able to confirm any of it by Google search,
but haven't been able to refute it either ...

Way back in the '80s when the unix terminal drivers and the original
"curses" packages were being invented, graphical windowing systems were
rare to non-existent.  Most computers were time-sharing systems accessed
via big cathode-ray-tube TV-set-like devices with built in keyboards,
which were called "terminals".  These were the same "terminals" that
were used for doing all kinds of data-entry and lookup tasks on mainframe 
computers running Unisys and IBM operating systems and other things most
of you probably never heard of and will never see.

There were no such things as mice; all cursor motion had to be controlled
with arrow keys on the keyboard or coded sequences from the application.

Data entry was often done using forms that filled the entire screen (all
80 columns and 24 lines of it, sometimes less, sometimes as many as 132
columns), laid out something like HTML forms, with labeled input fields;
but the application had to track the location of the cursor to know what
data was being entered in what field.

In other cases the application didn't really care where the cursor was,
the user of the terminal could move it around for his own purposes.

Consequently keyboards frequently had two operation modes:  One in which
the key press would cause the terminal's internal hardware to move the
cursor as well as send a sequence, and one where the character sequence
left the cursor unmoved but sent codes meant to be trapped so that the
application could later control the movement of the cursor.  When you
only had a few hundred baud of bandwidth to work with, moving the
cursor without having to transmit data in both directions might be a
huge benefit.

An application that needed to map the entire screen for data entry would
put the terminal in "application transmit mode" so that it could control
the cursor placement, and possibly optimize the instructions that it had
to send back to the terminal to move the cusor from field to field rather
than just one character up/down/left/right, again in the name of saving
precious bandwidth.

On top of this, many terminals had keypads that could be turned on and
off, the kind you still see on most PC keyboards with numbers and arrow
(and home/end/pgup/pgdn) keys overlaid.  "Newer" keyboards that had both
a separate set of arrow and paging keys along with a keypad could be
switched to have all the keys send distinct codes or to have the keypad
arrows send the same codes as the stand-alone arrow keys.  Others had
whole additional keypads for text editing operations, function key labels
overlaid on the paging keys, etc.  So there were all sorts of control
sequences that changed which keys sent what codes in what circumstances.
Sometimes there were custom hardware terminals for specific software
applications.

The termcap and terminfo databases and eventually a standard were all
developed to try to keep track of and make sensible use of all of this
complexity, and by now some of the distinctions and special cases have
mostly fallen into disuse ... but we're still left with emulators that
employ the standards and support the quirks of those old terminals.