MULTICS TECHNICAL BULLETIN
TO: MTB DISTRIBUTION
FROM: JON A. ROCHLIS
DATE: APRIL 2, 1984
SUBJECT: VIDEO FUTURES: NEAR TERM PLANS FOR THE MULTICS VIDEO SYSTEM
ABSTRACT
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
machines)
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;
where:
version
is the version number of the structure. The current version is
window_position_info_version_1.
column
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.
line
is the line of the upper left-hand corner of the window.
width
is the width of the window (columns).
Rochlis MTB 653 - Video Futures
height
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:
YANK_PREVIOUS_FROM_HISTORY (ESC-P)
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.)
YANK_NEXT_FROM_HISTORY (ESC-N)
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
place.
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.
where:
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.
where:
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:
set_kill_ring_size
Will set the size of the kill ring. This currently defaults
to ten.
set_history_size
Will set the number of history lines saved. It will
initially default to ten. [40? as in Unix?]
display_history
Will display the history list on the given window switch.
set_history_filter_size
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
tc_io_:
set_term_type
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
set_term_type_info.incl.pl1:
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
where:
version
is the version of the above structure. Currently it is
stti_version_1.
name
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
sent.
reconnection
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
re-initialized.
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
W_STATUS_SCREEN_INVALID and W_STATUS_ASYNC_EVENT.
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
4 USER SETTABLE DEFAULTS FOR WINDOW CREATION
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
commands.
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 window_io_.info 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 window_io_.info 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.
modes MODE_STRING
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 window_io_.info 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.
Notes:
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
5 GET_EDITOR_KEY_BINDINGS CONTROL ORDER
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
functionality.
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;
where:
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;
where:
version
is the version of the structure. It will be
set_editor_key_bindings_info_version_1;
replace
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.
update
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.
key_binding_info_ptr
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
pathname):
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
(line_editor_key_binding_info.binding_count)),
3 sequence char(line_editor_longest_sequence refer
(line_editor_key_binding_info.longest_sequence))
varying,
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);
Where:
name
is the name of the editor routine.
description
is a descripton of the function of the editor routine.
info_path
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);
where:
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
below.
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,
where:
version (input)
is the version number of the structure. This is currently
window_edit_line_version_2.
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)
where:
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,
MOVE_TO_BOL, BEGIN_UNDERLINE, END_UNDERLINE, BEGIN_HIGHLIGHT, and
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)
where:
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
window_info.incl.pl1:
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
where:
version
is the version number of the structure. It currently is
window_write_text_info_version_1.
Flags (the actions specifed take place if the flag is "1"b):
overstrike
the string is to replace any characters already on the screen.
(Note: one of insert or overstrike must be specifed, but not
both.)
insert
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.)
underline
the string is to be underlined.
inverse
the string is to be displayed in inverse video.
high_intensity
the string is to be displayed in high intensity.
low_intensity
the string is to be displayed in low intensity.
Types of error actions:
always_write
if the terminal doesn't support a request feature, write the
text normally.
report_errors
report unsupported operations by returning
video_et_$capabilities_lacking. Otherwise a zero error code
will be returned.
MTB 653 - Video Futures Rochlis
8 MISCELLANEOUS
8.1 OUTPUT CONVERSIONS
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.
8.2 DEFAULT KEY BINDINGS
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.
9.1 PERFORMANCE
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.
9.2 TESTING
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.
9.3 INCOMPATIBLE CHANGES
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
insensitive.
9.4 DOCUMENTATION
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 window_.info). 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
4 USER SETTABLE DEFAULTS FOR WINDOW CREATION 8
5 GET_EDITOR_KEY_BINDINGS CONTROL ORDER 12
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