DATE:         APRIL 2, 1984



This  MTB  describes  the   proposed  implementation  of  several
extensions  to the  Multics Video  System, including  support for
vertical  windows,  a history  mechanism,  improved reconnection,
output conversion tables, improvement of  the line editor and key
binding  mechanism,  user  settable   defaults  for  creation  of
windows, and TTF extensions.  Several of these are new proposals,
others are basically old proposals yet to be implemented.

Comments and  suggestions are most welcome.   They may be entered
in the System-M and MIT forum meetings:

               >udd>Multics>meetings>Video (tv)

or by electronic mail to:

               Rochlis.Multics  (on the  System-M, MIT,  and CISL

Those preferring traditional mail may send comments to:

               Jon Rochlis
               Honeywell Information Systems, Inc.
               Cambridge Information Systems Laboratory
               4 Cambridge Center
               Cambridge, MA    02142


Multics  Project  internal  working  documentation.   Not  to  be
reproduced outside the Multics Project without the consent of the
author or the author's management.

MTB 653 - Video Futures                                   Rochlis

                       1  VERTICAL WINDOWS

A  long standing  limitation of the  current video  system is the
lack  of  support  for  partial  screen  width  windows (vertical
windows, instead  of just horizontal).  Even  though space exists
for specifying window  widths in most of the  data structures, it
is not used.

The  first  step  is  to begin  using  these  fields,  adding the
appropriate  bounds  checking.   This gives  us  working vertical
windows,   but   without  scroll   regions,   insert/delete  line
capability, or other efficient display mechanisms.

To do  this the mbz  field in the  window_position_info structure
(defined in window_control_info.incl.pl1, and  used to define and
obtain information  about the position  on the screen  of a given
window) will become the column origin.  The new structure will be
as follows:

dcl       1 window_position_info
                              based (window_position_info_ptr),
            2 version         fixed bin,
            2 origin,
              3 column        fixed bin,
              3 line          fixed bin,
            2 extent,
              3 width         fixed bin,
              3 height        fixed bin;


   is the version number of the structure.  The current version is

   is the column of the upper left-hand corner of the window.  If this
   is zero then the first column will be used, to allow old programs
   written when this was a mbz field to run without modification.

   is the line of the upper left-hand corner of the window.

   is the width of the window (columns).

Rochlis                                   MTB 653 - Video Futures

   is the height of the window (lines).

Note: The following relations must hold when creating windows and will always
be true when obtaining information about a window.
  0 < column + width <= screen width
  0 < line + height  <= screen height

The  get_capabilities  control  order  will  return  the window's
capabilities,  if  performed  on  a  window_io_  switch,  and the
terminal capabilities if performed on  a tc_io_ switch.  There is
a  distinction because,  at least  initially, operations  such as
insert/delete  lines  will not  be  supported in  non  full width
windows.   This  is consistent  with  the current  action  of the
control order which  returns the window's size if  performed on a
window_io_  switch  and the  terminal's  size if  performed  on a
tc_io_ (or tty_) switch.

The second step, which will be implemented if demand for vertical
windows is great and as time permits, is to take advantage of the
video system's  screen state knowledge to  provide more efficient
display of vertical windows.  For  example, a CLEOL (clear to end
of line)  in a window that  occupies the left half  of the screen
can be done as a terminal  CLEOL if the corresponding line in the
right window (or windows) is clear.   Even if the right window is
not  clear, it  may be  less expensive  to CLEOL  and then redraw
characters in  the right window  rather than overwrite  spaces in
the  left  window,  depending  upon  whether  there  would  be  5
characters to redraw,  or 50, and the length  of the position and
CLEOL escape sequences.

It may also be possible to have really efficient vertical windows
on terminals  which support arbitrary  "region" definitions, such
as the Concept-100.   A new field in the  ttf would be necessary,
so that the video system would know to define a region, inside of
which  the normal  insert/delete line  sequences, etc.   could be
used,  without  disturbing  anything  else on  the  screen.  This
define region sequence  may only have to be  sent to the terminal
when defining or changing a window's bounds, or it may have to be
sent for each  operation to be performed on  such a region.  This
would depend upon how sophisticated the terminal was.

MTB 653 - Video Futures                                   Rochlis

                     2  A HISTORY MECHANISM

Several other operating systems,  most noteably Unix and Tops-20,
provide  a  history  mechanism  which  allows  users  to retrieve
previous  command  lines, edit  them, and  re-submit them  to the
command  processor.  Multics  has two separate  versions of this,
neither of which is quite good enough:

     1) The audit facility allows users to record their input and
     output, and to  edit it using a qedx  based editor.  However
     users must  explicitly invoke this facility,  and don't have
     the  real-time  editing  features  of  Emacs  available when
     editing a  line for resubmission,  much less the  ability to
     customize the facility in any way.

     2) The video system currently  saves its input buffer on the
     kill  ring whenever  a carriage return  is entered (actually
     whenever    a    key    sequence   which    is    bound   to
     TERMINATE_INPUT_LINE is  entered).  Users may  yank back the
     last command line with the YANK_FROM_KILL_RING request (^Y),
     assuming, of course, that they haven't deleted any text that
     has been saved on the kill  ring since they entered the last
     input  line.   Previous command  lines may  be put  into the
     current  input buffer  with the YANK_PREVIOUS_FROM_KILL_RING
     request    (ESC-Y)    which   may    be   given    after   a
     YANK_FROM_KILL_RING  request.   This  allows  users  to edit
     their  previous   ten  input  lines   using  the  extensable
     real-time video system line editor.

The problem with the using the video system's kill ring mechanism
for implementing  history is that  the input lines  really aren't
"killed" text and don't belong on the kill ring at all.  Also the
kill  ring  as currently  implemented only  allows users  to move
through  the  ring  in one  direction.   This is  okay  for small
chuncks  of  text  that  one  deletes  and  yanks  back,  but  is
inappropriate for manipulating past command lines.  Thus the kill
ring  will  be  changed to  store  only killed  text  (e.g.  text
deleted with the various editor  requests such as ESC-D, ESC-DEL,
etc.), and a new list of command lines, called the "history list"
will be created.

Two new requests will be provided to manipulate the history list:

          moves  the "current"  history line  pointer backward by
          one, and places that previous input line in the current

Rochlis                                   MTB 653 - Video Futures

          input buffer for editing.   An attempt to move backward
          beyond the  first history line will  cause the terminal
          bell to be sounded and no action to take place, instead
          of causing  the last history line  to be yanked.  (i.e.
          The history list, as seen by the user, is not a ring.)

          moves  the  "current" history  line pointer  forward by
          one,  and  places  the  next saved  input  line  in the
          current input  buffer for editing.  An  attempt to move
          forward beyond the last entered history line will cause
          the  terminal's  bell to  ring  and no  action  to take

The  following new  entry points in  window_editor_utils_ will be
provided so  that user written editor  requests may have complete
control over the history list.  (It isn't clear exactly what such
routines would  want to do  with the history list,  but since the
functionality must  be at least be  provided internally, we might
as well let users at it in the name of flexibility.)

History line numbers range from 1 to the size size of the history
list.  Giving an invalid history line  number to any of the below
routines will result in the error code video_et_$bad_history_line
being  returned.  This  will always happen  if they  are passed a
history number greater than the history size, and may happen if a
history line which doesn't exist is requested (i.e.  request line
N when less than N lines have be read from the given window).

dcl window_editor_utils_$yank_previous_from_history (ptr, fixed bin(35))
call window_editor_utils_$yank_previous_from_history (lei_ptr, code)

Subroutine interface to the YANK_PREVIOUS_FROM_HISTORY request.

dcl window_editor_utils_$yank_next_from_history (ptr, fixed bin(35))
call window_editor_utils_$yank_next_from_history (lei_ptr, code)

Subroutine interface to the YANK_NEXT_FROM_HISTORY request.


lei_ptr (input)
   is a pointer to a line_editor_info structure.

code (output)
   is a standard error code.

dcl window_editor_utils_$get_history_line (ptr, fixed bin, char(*),
          fixed bin(35))
call window_editor_utils_$get_history_line (lei_ptr, line_number,
          text, code)

MTB 653 - Video Futures                                   Rochlis

Gets the text of a history line without affecting the current history line.


lei_ptr (input)
   is a pointer to a line_editor_info_structure.

line_number (input)
   is the history line number desired. If zero, the current history line
   will be returned.

text (output)
   is the text of the history line designated.

code (output)
   is a standard error code.

Four new control orders will be supported:

     Will set the size of the kill ring.  This currently defaults
     to ten.

     Will  set  the  number  of  history  lines  saved.   It will
     initially default to ten.  [40?  as in Unix?]

     Will display the history list on the given window switch.

     sets the  minimum length required  to save an  input line in
     the history mechansim.  This can be used to filter out "yes"
     and "no" type responses, whose  value on the history list is
     questionable.  The  default value will be  zero, so that all
     input lines are saved.

The get forms of the set control orders will also be supported.

Note:  there  is no distinction  between input lines  and command
lines (as is done in Unix).   The video system cannot tell who is
calling  it and  it is probably  more valuable to  save all input
lines anyway (something Unix won't let you do).

Rochlis                                   MTB 653 - Video Futures

                         3  RECONNECTION

Current  re-connection technology  has sus_signal_handler_ close,
detach, attach, and open the -login_channel io switch.  Actually,
the switch opened is attached with an attach description of "tty_
-login_channel".  The video system gets around this by initiating
tc_io_  with  the  refname of  tty_  and having  tty_attach  be a
synonym for  tc_io_attach entrypoint, so that  at reconnection it
is the tc_io_  switch which is re-opened, not  the tty_ switch as
sus_signal_handler_ thinks.

Part of  the problem is  that the tc_io_  loses all of  its state
information  when  detached and  closed.   (The issue  about what
state  information  tc_  should   keep  will  be  addressed  when
designing full  windowing.)  For now,  sus_signal_handler_ should
be modified to first try issuing the "reconnection" control order
on the  -login_channel switch.  If  this works then  all is fine,
otherwise it would continue to try to detach, close, attach, open
the -login_channel switch.

In order to support this, two new control orders will be added to

     takes  a  pointer  to  a  set_term_type_info  structure (see
     below)  and  changes  the  terminal  type.   This  will  set
     window_status_pending for all windows and set a new field in
     the  window_status  structure called  ttp_change  along with
     screen_invalid.   This operation  will re-initalize  all the
     terminal specific video system information such as the video
     sequences, length of the screen, width, and capabilites.  In
     essence it will be  equivalent to doing "window_call revoke;
     stty  -ttp  new_terminal_type;  window_call  invoke", except
     that no windows will be destroyed.

     The    set_term_type_info    structure   is    declared   in

     dcl 1 set_term_type_info aligned based (sttip),
         2 version fixed bin,
         2 name char (32) unal,
         2 flags unal,
           3 send_initial_string bit (1),
           3 set_modes bit (1),
           3 ignore_line_type bit (1),
           3 mbz bit (33);

MTB 653 - Video Futures                                   Rochlis


       is the version of the above structure.  Currently it is

        is the name of the new terminal type.

     The set_inital_string, set_modes, and ignore_line_type flags
     are all ignored by the video system. The initial string will always be

     will determine the  new terminal type (which may  or may not
     be the same as before the disconnection), and will perform a
     set_term_type control order to inform the rest of the system
     of the change in terminal  type.  If the set_term_type fails
     for any reason,  video_utils_$turn_off_login_channel will be
     called in an attempt to  re-attach tty_.  (This will prevent
     the  current  behavior  in  which  reconnection  attempts on
     unsupported  terminal  cause fatal  process errors.)   A new
     field in window_status, called  reconnection, will be set to
     indicate  to  application  doing  get_window_status  that  a
     reconnection    has    occurred.     The    ttp_change   and
     screen_invalid bits in window_status  will already have been
     set  by  the  set_term_type  operation.   Other per-terminal
     information,  such  as devx  and  line speed,  will  also be

The      new     window_status      structure     (defined     in
window_status.incl.pl1) will be:

declare   1 window_status     aligned,
            2 screen_invalid  bit (1) unaligned,
            2 async_change    bit (1) unaligned,
            2 ttp_change      bit (1) unaligned,
            2 reconnection    bit (1) unaligned,
            2 mbz             bit (32) unaligned;

In addition the new constants W_STATUS_TTP_CHANGE and
W_STATUS_RECONNECTION will be defined to supplement the existing

Note:  the version number  of the window_status_pending structure
(defined in window_control_info.incl.pl1)  will be incremented to
prevent    the    video    system    from    mis-interpreting   a
set_window_status  control  order,  since  the mbz  field  in the
window_status structure was formerly  a pad field.  Both versions
will  be  supported.   Users  can only  access  the window_status
structure via the  window_status_pending structure, by performing
the get_window_status and set_window_status control orders.

Rochlis                                   MTB 653 - Video Futures


Currently when the video system creates a new window it must pick
reasonable default values for many of the window attributes, such
as  more  prompt,  conversion  tables, and  key  bindings.  These
defaults are hard-coded in  various modules, including window_io_
and window_io_iox_.  Users who  wish to customize windows created
by their applications can perform control orders on their windows
after  creation.   But  some  applications, like  XMAIL,  have no
facility for letting users customize the windows they create, nor
should  they be  required to have  such a  facility.  Instead the
video system should provide a  mechanism for setting defaults for
all newly  created windows.  This would  still allow applications
to override  the defaults, by performing  standard control orders
on their windows.

For  example, consider  the XMAIL  user who  uses more_mode=fold.
When XMAIL  creates its window  for displaying mail,  that window
will  have the  standard default more  mode of  scroll.  The user
will be confused when his mail scrolls by, instead of folding, as
he is used to at command level.  The user will be frustrated when
he discovers that there is no way to change this from XMAIL.

A  new  command  set_video_defaults  will  be  written.   It will
support  all of  the "customizing" control  orders of window_io_.
The values set however, will be stored in the data section of the
user's  default value  segment and  will be  used as  the default
values whenever a  new window is created.  An  option to set only
per-process defaults will also be implemented.

For   example,   the   command   "set_video_defaults  more_prompt
--more--"  would set  the default  more prompt  for newly created
windows to be "--more--" instead of "More?  (RETURN for more; DEL
to discard output.)".

There  will   also  be  corresponding   print_video_defaults  and
delete_video_defaults commands.

There will be some small  internal video system reorganization to
support the  new commands.  The  standard defaults will  be moved
(as much as possible) to video_data.cds, instead of their current
disorganized  home  in  assignment  statments  in  window_io_ and
window_io_iox_.  Wioctl_ will be modified to be of use to the new

Here are info  segs for set_video_defaults, print_video_defaults,
and delete_video_defaults:

MTB 653 - Video Futures                                   Rochlis

03/11/84 set_video_defaults, svd

Syntax: set_video_defaults key args {-control_args}

Function: defines default values newly created windows.

Control arguments:
-perprocess, -pp
    specifies that values set should not be stored in the user's
    default value segment, but instead should be remembered only for
    the life of the current process.
-permanent, -perm (default)
    specifies that values set should be stored in the user's default
    value segment.

List of keys:

editor_key_bindings key-sequence bindings-args
   sets default editor key bindings.  key-sequence is the key sequence to be
   bound, only one key sequence is allowed.  binding-args are any arguments
   acceptable to the io_call form of the set_editor_key_bindings control
   order. (See for more information.)

token_characters STR
   sets the characters which are used by the line editor to delimit
   words.  STR should contain all characters which are to be considered
   part of a word.

more_handler more_handler_name
   specifies that the procedure more_handler_name should be called at
   a more break. (See for more information.)

more_responses yes_responses no_responses
   sets acceptable responses for more breaks.

more_prompt STR
   sets the string displayed at more breaks.

   see List of modes for the various modes which may be set.

List of modes:

more, ^more
   enables or disables more processsing.

more_mode = STR
   controls behavior when the window is filled.  STR must be one of scroll,

Rochlis                                   MTB 653 - Video Futures

   wrap, fold, or clear. (See for more information on the
   different modes.)

vertsp, ^vertsp
   is only effective when the more mode is on.  When vertsp mode is on,
   output of a FF or VT will cause an immediate MORE query.  The
   default is ^vertsp.
rawo, ^rawo
   causes characters to be output with no processing whatsoever.  The
   result of output in this mode is undefined.
can, ^can
   causes input lines to be canonicalized before they are returned.
   The default is on.
erkl, ^erkl
   controls the editing functions of get_line.  The default is on,
   which allows erase and kill processing and the additional line
   editor functions.

esc, ^esc
   controls input escape processing.  The default is on.
rawi, ^rawi
   acts as a master control for can, erkl, and esc.  If this mode is
   on, none of the input conventions are provided.  The default is on.
red, ^red
   controls interpretation of red shift and black shift characters on
   output.  The default is ^red, which ignores them.  In red mode, the
   character sequence given in the TTF is output.  The effect is
   undefined and terminal-specific.  In some cases, "red shifted"
   output appears in inverse video, but this is not guaranteed.


All defaults set by this command take effect at once.  Any new
windows created will be created with the new defaults.  Already
existing windows are not affected.

03/11/84 print_video_defaults, pvd

Syntax: print_video_defaults {key1 ... keyN} {-control_args}

Syntax as an active function: [print_video_defaults key1 ... {keyN}]

Function: prints default values for newly created windows.

Control arguments:
-perprocess, -pp (default)

MTB 653 - Video Futures                                   Rochlis

    specifies that per-process defaults should be listed rather than
    permenant defaults.
-permanent, -perm
    specifies that permanent defaults should be listed, even if there
    are currently per-process defaults in effect.
-all, -a
    specifies that both permanent and per-process values should be listed.
    This is not allowed if used as an active function.

Where: key is a valid key accepted by set_video_defaults. If key is modes
    then a mode string must also be supplied.

03/11/84 delete_video_defaults, dvd

Syntax: delete_video_defaults key {key2 ... keyN} {-control_args}

Syntax as an active function: [delete_video_defaults key1 ... {keyN}]

Function: deletes default values for newly created windows.

Control arguments:
-perprocess, -pp (default)
    specifies that per-process defaults should be deleted rather than
    permenant defaults.
-permanent, -perm
    specifies that permanent defaults should be deleted, even if there
    are currently per-process defaults in effect.
-all, -a
    specifies that both permanent and per-process values should be deleted.
    This is not allowed if used as an active function.

Where: key is a valid key accepted by set_video_defaults. If key is modes
    then a mode string must also be supplied.

Rochlis                                   MTB 653 - Video Futures


A  get_editor_key_bindings  control  order should  be  written to
complement  the set_editor_key_bindings  control order.   Given a
key    sequence(s)    it    should    return    a    pointer   to
line_editor_key_binding  structure  describing the  key bindings.
io_call  support  should print  out the  pathname of  each editor
routine, listing  only the names  of builtin requests  in capital
letters   with   the   word   "builtin"   in   parentheses.   The
DISPLAY_EDITOR_DOCUMENTATION  builtin  should  be  able  to  take
advantage  of  this.  It  should also  be able  to obtain  just a
pointer representing the entire  state of the editor keybindings,
so that  push/pop operations can  be performed more  easily.  The
proposed    window_$edit_line    entrypoint   will    need   this

The  get_editor_key_binding_info  structure will  be  created and
defined in window_control_info.incl.pl1:

dcl 1 get_editor_key_bindings_info
          aligned based (get_editor_key_bindings_info_ptr),
      2 version                char(8),
      2 flags,
        3 entire_state         bit (1)  unaligned,
        3 mbz                  bit (35) unaligned,
      2 key_binding_info_ptr   ptr,
      2 entire_state_ptr       ptr;


version (input)
   is get_editor_key_binding_info_version_1.

entire_state (input)
   is "1"b if the entire state is desired, "0"b if only
   information about certain keybindings is desired.

key_binding_info_ptr (input/ouput)
   If entire_state = "0"b then this points to a
   line_editor_key_binding_structure. The bindings
   component of this structure is then filled in based
   upon the value of each key_sequence supplied.

entire_state_ptr (output)
   is set to point to the "state" of the key bindings, if
   entire_state = "1"b.  This is suitable input to the
   set_editor_key_bindings control order.

MTB 653 - Video Futures                                   Rochlis

The  set_editor_key_bindings  control  order will  be  changed to
accept a pointer to the following structure.  It will continue to
accept the simple case of  a pointer to a line_editor_key_binding
structure as well (aren't version numbers wonderful).

dcl 1 set_editor_key_bindings_info
          aligned based (set_editor_key_bindings_info_ptr),
       2 version              char(8),
       2 flags,
         3 replace            bit (1) unaligned,
         3 update             bit (1) unaligned,
         3 pad                bit (34) unaligned,
       2 key_binding_info_ptr ptr;


   is the version of the structure.  It will be

   if "1"b then key_binding_info is considered to be
   returned by a previous get_editor_key_bindings operation
   with entire_state = "1"b, and will be used to replace the
   keybinding state of the editor.

   if "1"b then key_binding_info_ptr is considered a pointer
   to a line_editor_key_binding_info structure, which will be used
   to update the keybinding state of the editor.

Note: only one of replace and update may be true, but at least one of them
must be true.

   is a pointer received from get_editor_key_bindings operation
   or a pointer to a line_editor_key_binding_info structure,
   depending on the value of the replace and update flags.

Notes on freeing: The video system's internal data structures are freed at two
times: video system revocation and when a set_editor_key_bindings control
order with repalce = "1"b is done.

The   line_editor_key_bindings   info   structure   (declared  in
window_control_info.incl.pl1)  will  also be  changed  to include
several  info  strings (a  name,  a decription,  and an  info seg

dcl  1 line_editor_key_binding_info
                              aligned based (line_editor_key_binding_info_ptr),
       2 version              char(8),

Rochlis                                   MTB 653 - Video Futures

       2 binding_count        fixed bin,
       2 longest_sequence     fixed bin,
       2 bindings             (line_editor_binding_count refer
         3 sequence           char(line_editor_longest_sequence refer
         3 action             fixed bin,
         3 numarg_action      fixed binary,
         3 editor_routine     entry (pointer, fixed bin(35)),
         3 name               char (64) varying,
         3 description        char (256) varying,
         3 info_path,
           4 info_dir         char (168),
           4 info_entry       char (32);


   is the name of the editor routine.

   is a descripton of the function of the editor routine.

    is the pathname of an info segment describing the editor rouitne.

MTB 653 - Video Futures                                   Rochlis

                   6  THE VIDEO SYSTEM EDITOR

A  rather substantial  line editor has  evolved out  of the video
system's iox_ emulator, allowing callers of iox_$get_line to reap
the  benefits.  Calling  iox_$get_line with  video invoked allows
users  to  edit their  input  line with  a  powerful, extensible,
subset of Emacs.

Unfortunately, callers of the various window_ entry points cannot
use  the line  editor.  To  do so  they must  call iox_$get_line,
which is often undesirable because of the possible effects on the
screen.   For example,  the user  may type  control-L causing the
window  to be  erased, or  the user may  enter a  long input line
which wraps and overwrites the next line or two.

In addition, the video line editor has also turned window_io_iox_
into the largest  single module in the video  system, and this is
beginning to cause maintenance  problems.  At least two-thirds of
the 3500 lines of this module belong to the guts of the editor.

It is about time to move the  editor out of the iox_ emulator and
to  make  it available  from outside  the iox_  framework.  There
should be a  window_ interface to the editor,  which allows users
to  set special  "local" keybindings, pre-load  the input buffer,
start  input at  an arbitrary position  in the window,  and put a
limit on  the length of  input.  Once this  is done iox_$get_line
simply becomes a caller of this window_ entrypoint.

Thus window_$edit_line will added to window_:

dcl window_$edit_line entry (pointer, pointer, pointer,
          fixed bin(21), fixed bin(21), fixed bin(35));

call window_$edit_line (iocb_ptr, window_edit_line_info_ptr, buffer_ptr,
          buffer_len, n_returned, code);


iocb_ptr (input)
          is a pointer to a window_io_ iocb from the input is to be read.

window_edit_line_info_ptr (input)
          is a pointer to a window_edit_line_info structure described

buffer_ptr (input)
          is a pointer to a buffer where the users input will be put.

Rochlis                                   MTB 653 - Video Futures

buffer_len (input)
          is the size of the input buffer.

n_returned (output)
          is the number of characters in the final input line.

code (output)
          is a standard error code.

The  window_edit_line_info  structure  is  declared  in  the  new
include file window_info.incl.pl1.  This new include file will be
the home  for information structures  used by window_.   (See the
section on TTF improvments for another stucture destined to be in
this include file.)

dcl 1 window_edit_line_info aligned based (window_edit_line_info_ptr)
      2 version     char(8),
      2 line_ptr    ptr,
      2 line_length fixed bin,
      2 key_binding_info_ptr ptr,
      2 max_length  fixed bin,
      2 prompt      char(128),
      2 coords,
        3 column    fixed bin,
        3 line      fixed bin,


version (input)
          is the version number of the structure.  This is currently

line_ptr (input)
          is a pointer to the initial text string.

line_length (input)
          is the length of the string pointed to by line_ptr.

key_binding_info_ptr (input)
          is a pointer to the info structure describing key bindings
          suitable for a set_editor_key_bindings control order.

max_length (input)
          is the maximum length of input which should be accepted.

prompt (input)
          is a prompt to be displayed before the initial string.

column (input)
          is the column of the window where the prompt string (if any)
          will be displayed.

MTB 653 - Video Futures                                   Rochlis

line (input)
          is the line of the window where the prompt string (if any)
          will be displayed.

The prompt will  cannot be edited, the inital  cursor position is
directly  after the  prompt string, and  conversions and wrapping
will be done.

Also              window_$set_editor_key_bindings             and
window_$get_editor_key_bindings  will  be  added  to  window_  to
support key bindings from outside of the iox_ framework.

dcl window_$set_editor_key_bindings entry (ptr, ptr, fixed bin(35))

call window_$set_editor_key_bindings (iocb_ptr, info_ptr, code)


iocb_ptr (input)
   is a pointer to a window_io_ iocb.

info_ptr (input)
   is a pointer to a set_editor_key_bindings_info structure.

code (output)
   is a standard error code.

window_$get_editor_key_bindings is  exactly the same  except that
the info_ptr points to a get_editor_key_bindings structure and is
an  output variable  (see the  section on get_editor_key_bindings
for more info).

Notes   on   key  bindings   and   window_:   bindings   set  via
window_$set_editor_key_bindings will  effect all future  calls to
window_$edit_line (but  not iox_$get_line), bindings  set via the
set_editor_key_bindings  structure  in  window_edit_line_info are
local  and  only last  for the  duration of  the edit  line call.
Since  performance  may not  be acceptable  if an  application is
doing a lot of key binding, applications may elect to make use of
the window_$(set get_)_editor_keybindings entries.

Rochlis                                   MTB 653 - Video Futures

                       7  TTF IMPROVEMENTS

There are several attributes of many modern video terminals which
are not described in the  current TTF language or data structure.
Many  of  these  attributes  are  either  state  flags  or simple
character sequences, and can therefore  be handled by the current
TTF and video data implementation.  These attributes include such
features as  whether or not the  terminal can overstrike, whether
or not  the terminal has native  full-screen scrolling, the begin
and  end  highlighting  sequences,  the begin  and  end underline
sequences (if any), and the clear  to beginning of line and go to
beginning of line sequences (if any).

Several new keywords will be added  to the TTF format to describe
these new  sequences.  Their syntax follows  that of the existing
keywords  (e.g.   cursor_up).   These  keywords  are move_to_bol,
clear_to_bol,  begin_underline,  end_underline,  begin_highlight,
and  end_highlight.   The  state  flags  will  be  specified  via
keywords that  take no arguments.  These  keywords are overstrike
and native_scroll.  To complete support for these new fields, the
data structure  returned by ttt_info_$video_info  must be changed
to include  the new fields, and  new primitive terminal sequences
must  be defined.   The native_scroll  bit will  be added  to the
flags section of the  tty_video_table data structure (declared in
tty_video_tables.incl.pl1), and the named constants CLEAR_TO_BOL,
END_HIGHLIGHT  will  be  added  to  represent  the  new  terminal
sequences.  These changes are  completely upwards compatible with
the  current version.   Nevertheless, the  version number  of the
tty_video_table structure will  be changed from 1 to  2 to ensure
that  an  application written  to  rely on  the  new flag  in the
version 2 structure never mistakenly calls a version of ttt_info_
that only supports the version 1 structure.

The       capabilities_info      structure       (defined      in
terminal_capabilities.incl.pl1) will be changed to have flags for
these new capabilites.

tc_request  will  then  be  modified to  make  use  of  these new
features and a window_  interface for them (especially underline,
and highlight) will also be provided.   It is my feeling that the
highlight and underline fields should  only be used for terminals
which will not  require the video system to  manage anymore state
information  about the  screen than is  already maintained.  Thus
the  video  system  would  assume,  and  user  applications could
assume, that the effects writing highlighted text would be undone
the next time something was  written at that screen position, and

MTB 653 - Video Futures                                   Rochlis

would  move if  the screen was  scrolled, etc.  Thus  we would be
postponing dealing with the much  harder issues of real attribute
management,  which  must  be addressed  if  we are  ever  to make
effective  use  of  highlighting  type  features  of VIP7801-like
terminals,  but  in  the mean-time  we  would easily  be  able to
support these features for VT100, H19 type terminals.

Thus window_$write_text will  be added to window_.  It  will be a
more general  interface for writing ascii  strings (as opposed to
window_$write_raw_text)  to  the  terminal.  It  can  replace the
window_$insert_text  and window_$overwrite_text,  but since these
entrypoints are heavily used today,  and don't require setting up
a strucutre, they will be untouched and will stay in window_:

dcl window_$write_text (pointer, pointer, char(*), fixed bin(35))
call window_$write_text (iocb_ptr, info_ptr, string, code)


iocb_ptr (input)
   is a pointer to a window_io_ iocb

info_ptr (input)
  is a pointer to a window_write_text_info stucture (declared in
  window_info.incl.pl1, see below).

string (input)
  is the character string to be written to the window.  It must contain
  only single width printable ascii characters.

code (output)
  is a standard system error code.

The    window_write_text_info    structure    is    declared   in

dcl 1 window_write_text_info
          aligned based (window_write_text_info_ptr),
      2 version             char(8),
      2 flags,
        3 overstrike        bit(1)  unaligned,
        3 insert            bit(1)  unaligned,
        3 underline         bit(1)  unaligned,
        3 inverse           bit(1)  unaligned,
        3 high_intensity    bit(1)  unaligned,
        3 low_intensity     bit(1)  unaligned,
        3 mbz               bit(30) unaligned,
      2 error_action,  /* for unsupported operations */
        3 always_write      bit(1)  unaligned,
        3 report_error      bit(1)  unaligned,
        3 mbz               bit(34) unaligned;

Rochlis                                   MTB 653 - Video Futures


   is the version number of the structure.  It currently is

Flags (the actions specifed take place if the flag is "1"b):

   the string is to replace any characters already on the screen.
   (Note: one of insert or overstrike must be specifed, but not

   the string to to be inserted at the current cursor position,
   rather than replacing existing characters.  (Note: one of
   insert or overstrike must be specifed, but not both.)

   the string is to be underlined.

   the string is to be displayed in inverse video.

   the string is to be displayed in high intensity.

   the string is to be displayed in low intensity.

Types of error actions:

   if the terminal doesn't support a request feature, write the
   text normally.

   report unsupported operations by returning
   video_et_$capabilities_lacking.  Otherwise a zero error code
   will be returned.

MTB 653 - Video Futures                                   Rochlis

                        8  MISCELLANEOUS


Support for the (get set)_output_conversion and (get set)_special
control  orders  will  be  added to  window_io_.   These  will be
indentical to  the tty_ control  orders, except that  the default
tables will not  be those in defined the TTF,  but rather will be
those in use before video is invoked.


The default key bindings for builtin editor requests will be made
case insensitive, in  an attempt to be more  user friendly and to
be more  like Emacs For example,  the FORWARD-DELETE-WORD request
will be bound  to ESC-D as well as ESC-d.   This will not prevent
users from changing  the bindings in a manner  which depends upon
case  (via the  set_editor_key_bindings control  order), but will
make the default more palatable to the novice user.

Rochlis                                   MTB 653 - Video Futures

                          9  CONCLUSION

Several concluding details must be considered.  These include how
the  propossed  changes  affect  performance,  how  they  will be
tested, and how they will be documented.


The performance of the video system is a serious question, and we
must be  careful not to degrade  performance unless the increased
functionality is  clearly worth the cost.   None of the proposals
in  the MTB  require extensive changes  in critical  paths of the
video  system,   most  deal  with  window   level  functions  not
frequently  invoked,  such  as  the key  binding  control orders,
rather than the  terminal control code invoked to  read and write
characters.   Nonetheless several  things may  affect performance
(vertical windows, ttf changes), and  a set of scripts to compare
present  performance  with  changes  will be  developed.   In the
process of this we may  discover some of the performance problems
with the video system and solutions may be devised.


Virtually all of  the testing can be obtained  through the normal
path  of  EXL  exposure   along  with  several  incremental  >sss
installations  along  the  way.    There  are  only  two  changes
suggested which require testing other parts of the system besides
the  video  system.  These  include  the TTF  changes,  for which
separate copies of the TTF software  (and indeed the TTF) will be
maintained in EXL  for testing.  The other area  is the change to
sus_signal_handler_ which will be tested on the CISL machine.


There  are very  few incompatible changes,  and most  of them are
minor.  Through the careful use of version numbers and mbz fields
old versions of structures will still be accepted.  The following
are user visible incompatible changes:

MTB 653 - Video Futures                                   Rochlis

1)  Stopping  the storage  of input  lines on  the kill  ring and
moving their storage to the history mechanism.

2) Changing the  "pad" field in the window_status  structure to a
"mbz" field.

3) Making the  default key bindings for builtin  requests be case


Apropriate   documentation  should   be  included   in  CP51  and
MPM/Subroutines manuals.  Descriptive  sections about the history
mechanism and window creation defaults  should be worked into the
descriptive  material  in  CP51  and the  MPM.   The  various new
window_  entry  points  should  be  described  in  CP51  and  the
subroutines  manual (as  well as  Descriptions of
the new control  orders should also find their  way into CP51 and
the IO module portion of the subroutines manual.  The TTF changes
should  be  reflected in  the  documentation for  cv_ttf  and the
subroutine ttt_info_.

MTB 653 - Video Futures                                   Rochlis

                        Table of Contents

1      VERTICAL WINDOWS                                 1

2      A HISTORY MECHANISM                              3

3      RECONNECTION                                     6



6      THE VIDEO SYSTEM EDITOR                         15

7      TTF IMPROVEMENTS                                18

8      MISCELLANEOUS                                   21
8.1    Output Conversions                              21
8.2    Default Key Bindings                            21

9      CONCLUSION                                      22
9.1    Performance                                     22
9.2    Testing                                         22
9.3    Incompatible Changes                            22
9.4    Documentation                                   23