C/C++ Interactive Guide/c-cplusplus-interactive-guide.iso/c_ref/csource5/331_01/read.me

Text File | 1990-06-15 | 25KB | 439 lines

.ce
                             The SE Editor

.fi
.rm 76

This file announces the release of yet another of the derivatives of the 'e'
editor.  The highlights of this version are:

1) Utilizes up to 500 kb of RAM for text storage, while functioning with as
little a 6kb of allocatable memory. 2) The efficiency of the virtual disc
system has been doubled by adding a stale page directory.  The speed of disc
reads has been improved. 3) An embedded runoff function will reformat
internal text per dot commands. 4) A text push stack has been added for
pushing and popping lines. 5) The undo capability has been extended to
include redo. 6) The program supports free cursor movement. 7) Numerous
enhancements to the command and display structure have been made, while
retaining Wordstar [1] compatibility where feasible and reasonable.  Many of
the enhancements are cosmetic, not affecting the command structure, but
improving the visibility or convenience of use.

The starting point for this system was the GED version, CUG 199.  The
contributors to that version were G.  Nigel Gilbert, James W.  Haefner, and
Mel Tearle.  Several small errors have been corrected.  The new version
compiles under Microsoft 4.00.  This compiler allows selective use of far
pointers, opening up the possibilities of the large memory model without its
usual inefficiency.  Some effort has been made to otherwise maintain
compatibility with the DeSmet starting point, but the thoroughness of the
compatibility has not been tested.

The architecture remains that of the earlier versions.  It is a good
architecture, providing a solid foundation for further enhancements and
additions.  Due to the ancestry of the program, the architecture is oriented
to the needs of a slow remote terminal.  In the interest of portability,
that design philosophy has been retained, even though some shortcuts could
have been taken with the direct access to the video RAM in the PC's.  The
shortcuts would compromise the portability of the program.

There are preprocessor directives in the header file which can be changed to
remove all occurrences of the near and far keywords, making the code
compatible with compilers which do not support mixed memory models.  Most
users will not find the capabilities of the program running under the small
memory model overly restrictive.  The virtual memory system is effective in
masking the shortcomings of a small RAM.

A tidying up operation has been performed, including the addition of many
comments.  The new code, now in its third compiler port, should be mostly
vanilla.  An attempt has been made to further segregate those functions
which are system dependent (IBM PC, MSDOS) to simplify rework for a port to
a different system.  The strategy in porting the system to an entirely
different environment is to replace the system interface routines
altogether.

The program is configured for editing a 2.4 megabyte english dictionary
consisting of 10000 lines of 253 characters each.  The maximum file size
will be less for 80-character lines.  The maximum number of lines in a file
is 16383.

The line limit may be less for small memory systems, but remains adequate
for most work in any plausible system. 1000 line files can be edited with
only 8 kb of allocatable RAM.  A line pointer array is kept in RAM, so all
line jumps are instantaneous if the text is in RAM, or just the disc access
time (without searching) if all the document won't fit in RAM.  The virtual
memory system keeps the most recently used pages in RAM, as they are the
most likely to be used or viewed again.  Global string searches have little
effect on the established page priorities.  They normally search all pages
and are given special consideration so that they do not upset the virtual
memory priorities established by earlier editing and display functions.

Earlier versions unconditionally wrote a page back to disc if the RAM slot
was needed for another use.  This version does not do a disc write if the
virtual memory page is unchanged since being rolled in from disc.  In a
further refinement, the line pointer array and text pages are allocated
beginning from opposite ends of memory, so that they do not collide until
RAM is exhausted.  Collision was immediate in the earlier versions,
resulting in unnecessary disc thrashing during the initial read.  If enough
RAM is available the new version will not create a temporary disc file at
all.

Tree directories are supported.  An error in earlier versions which made
filespecs of the form ..\filespec unusable has been corrected.  The
temporary disc file normally goes in the default directory of the default
drive.  The -D invocation option can be used to place the temporary file on
any drive.  In browsing through the files on floppy discs from a hard disc
system, nothing is written to the floppy disc unless directed there from the
keyboard.  Archived files can be studied with little risk of accidental
modification.

The program updates the screen before the data base, making it seem faster
than it is in some cases.  In the case of line deletions or insertions, all
the line pointer array beyond the modified point is moved.  The processing
delay is seen if a second key is entered during the move.  The delay becomes
noticeable and objectionable at about 5000 lines on a 5 MHz PC.  The delay
is not objectionable (and rarely seen) with 16000 line documents on an 80286
or faster system.

On a 5 MHz PC the primary file is read at the rate of 5200 characters per
second from fixed disc; at 3000 characters per second from floppies.  The
string search operation proceeds at 30,000 characters per second if the
material is in RAM.  The search rate exceeds 200,000 characters per second
on more recent systems.

Learning to use any word processor effectively represents a significant
investment in time.  For that reason I have tried to adopt or retain the
Wordstar keyboard layout for the frequent and habitual keystrokes.  But in
the more complex and less frequent functions, and when there is is ample
visual prompting or feedback, significant deviations have been made.

Some editing programs trap the cursor within the portion of the screen
containing text for reasons which are surely without merit.  The package has
been modified to allow free cursor movement.  The horizontal domain of the
cursor lies between columns 1 and 255.  The ^D, right arrow, and ^] (end of
line) cursor positioning commands will move the cursor past the right end of
the line.  Doing so creates temporary spaces at the end of the line, but
they are removed before the line is stored.  Editing is performed as though
each line had spaces all the way to the right.  Free cursor movement is a
great convenience in editing C code because the cursor will stay at a fixed
indentation level when moved vertically.

The -S option restores the earlier mode.  In this mode the cursor is trapped
within those regions already containing text (or trailing spaces).  In this
mode it is unnecessary to strip trailing blanks before lines are stored, and
they are not.  That is what the mode used for.  But otherwise, the first
time a file passes through SE without the -S option it may shrink in size
without any editing activity.  The thing lost is trailing whitespace.

The GED version had a full undo capability, but I quickly discovered that
after undoing more than two lines I had always forgotten what I had changed
and why.  The changes I saw occurring on the screen in time reversal didn't
make any sense.  To overcome that problem I modified the undo algorithm to
be reversible and with that there is redo.  The same algorithm and the same
code is used for both.  The complete algorithm is surprisingly compact.  By
moving back and forth along the edit trail it is usually possible to
recognize the correct restoration point many lines back.  Undo is nice, but
it is redo that makes it work.

As each line is undone or redone it appears in reverse field on the screen.
The cursor follows the undone and redone lines about th