Programmer 7500/MAX_PROGRAMMERS.iso/INFO/MISC/TNH_PC.ZIP/ALBERT.NL

Text File | 1987-01-14 | 10.1 KB | 317 lines

Personal Editor

              Jim Albert
      Endicott Owego User Group

Personal Editor (PE) is both my
absolute favorite piece of PC
software, and my all-time favorite
text editor.  (I am including
mainframe editors in the comparison,
so I hope this endorsement will not
be taken lightly.)

On to the review, then.

Personal Editor is a full-screen
text editor for the PC.  For those
of you who don't know, 'full screen'
means that the editor provides a
`window' into the file within which
the cursor may be freely moved and
changes made just like writing on
paper.  The alternative, a 'line
editor' (like EDLIN) limits the user
to a sequence of commands affecting
individual lines of the file.  The
term 'text editor' means that it is
designed to produce straightforward
files of characters rather than
finished documents.  The latter type
of editors are usually called 'word
processors' (like EasyWriter).
Personal Editor is suitable for a
variety of tasks including
programming, preparation of network
messages, and simple database
operations, but must be combined
with a 'text formatter' like
SCRIPT/PC.

Two additional characterizations
must be made to put Personal Editor
into its proper category before
getting down to particulars: First,
it is a 'keystroke oriented' rather
than a 'command oriented' editor.
This means that in most cases
operations are performed by striking
special keys - vector or function
keys, or 'ordinary' keys modified by
ALT or CTRL - rather than typing a
'command' composed of regular
characters on a special part of the
screen. XEDIT, EDGAR, and ESPF are
all 'command' editors.

Second, it is what I refer to as a
'two-dimensional' rather than a
'one-dimensional' editor.  Like
XEDIT on VM/SP, Personal Editor's
view of files is that they are
two-dimensional arrays of
characters, so many per record
'across'  and multiple records
'down'.  (I suspect this view of
files derives from punch-card
technology). What this means to the
user is that 'unused' space on the
screen is potentially useable - like
blank paper - and that the CRs at
the end of records are invisible
implementation details ('return' is
viewed as a cursor movement key).
Many non-IBM editors, on the other
hand, take an essentially
one-dimensional view of a file;
i.e., the file is viewed as one long
string of characters, punctuated
here and there with very real CRs.
Such editors follow the convention
of starting a new screen line every
time they encounter one of these,
but they don't really have a concept
of a file being a sequence of
records.  (I suspect that this view
of all things derives primarily from
telegraph technology.)  To the user
of such editors, this means that
blank space on the screen may be
'outside' the file and you can't
move the cursor there at all.  The
'return' key, on the other hand,
actually enters a CR into the file
(effectively 'splitting' a line).
CRs can be erased, as well.

The next characteristic I would like
to mention is, as far as I am aware,
unique to Personal Editor: The
mapping of editing 'functions' onto
keys (or key combinations) is
entirely user-controllable.  For
example, the left-arrow key moves
the cursor 1 character left - but
only because the default profile
relates the key 'left' with the
function named '[left]'.  The user
can in principle change this
mapping.  There is, of course, a
reasonable set of defaults provided
- which leads to a useful
digression: One of the first things
I tried was a re-mapping of the
keyboard to suit my fancy: for
example, 'Ctrl-PgUp' makes more
sense to me as a way of getting to
the top of the file than the default
'Ctrl-Home'.

One of the nicest things about
Personal Editor is that it is fast,
response time on all trivial
operations is undetectable.
Personal Editor is also very natural
to use, although some learning is
involved before you remember which
key does what.  As noted before,
there are no 'surprises' associated
with the behavior of the 'return'
key or blank space.

Personal Editor also has a 'serious'
level of capacity.  On a 128K
machine it has 68660 bytes available
in main store - and it can handle
bigger files than that by creating a
'spill file' on diskette.  Proof of
the pudding?  Would you believe I
use PE to edit a Newsletter, with
everything except inserts and the
Library list in at once? Most of the
'big editor' features are present -
HELP, split and join lines, locate,
global and local changes, repeat
execution of commands, editing up to
20 files at once, etc.  No, it can't
do everything - no SORT, for example
- but there are some nice features
you may not have seen before, like
'undelete' and paragraph reflow.

One group of features is worth at
least a paragraph on its own - the
block moves.  There are three ways
of 'marking' an area of text: 'line'
marks a group of lines, 'character'
marks a string of characters,
possibly spread over multiple lines,
and 'block' marks a rectangular area
by indicating two opposite corners.
In each case, the area marked is
clearly indicated by displaying it
in reverse video.  Having marked an
area, it is then possible to operate
on it - you can move it, copy it,
clear it to blanks (or whatever you
like), delete it entirely, or shift
it right or left.  The block marks
are something else again - but
terrific for moving columns of stuff
around, table manipulation, and the
like.  Except for move and delete,
the area remains marked until
explicitly unmarked, so it is
possible for example to make
multiple copies of an area.  A final
note on blocks - unlike the prefix
operators in XEDIT they do work
between multiple simultaneous files,
resulting in by far the nicest
approach to 'getfile' and 'putfile'
operations I have encountered.  To
include a piece of another file in
the one you are editing, there is no
line counting involved - edit both
files, line-mark the area you want,
and block-copy it into the target
file.  To extract a piece of a file,
you just edit a nonexistent file and
move or copy into it.

Now -  back to those re-definable
keys.  There are three ways to do
it: You can just issue a command,
for example

  def left = [right]

would cause the left-arrow key to
move the cursor right.  More
usefully,

def s-f7 = [shift left][shift left]
           [shift left][shift left]

would change the standard key for a
left block shift (shift-F7) to do
its thing four characters at a crack
instead of one - possibly a very
attractive modification for a Pascal
or C programmer, who could use it to
re-align blocks of indented code
after moving them.  However, this
would only last for the duration of
the session, and next time you'd
have to type the whole dreary mess
in again.  Well, if you are very
sure that you want to make the
change both permanently and for all
environments, you could just modify
the profile dataset that contains
the default key definitions, PE.PRO.
(Excuse me, someone in the back row
wants to know if there is also a
'PE.KEY' file.  Strange question -
but the answer is no, there isn't.)
If you aren't convinced that you
want to modify PE.PRO, or if you
have different reassignments in mind
for different environments, the
third method is what I would really
recommend: You can build a file of
definition commands with some other
name, and invoke it after you enter
the edit session with the MACRO
command.  (Incidentally, there is a
command area for things that have to
be typed out, like definitions and
global changes.  You get there and
back with the Esc key.)  A couple of
examples I use: for GML operations,
I have Alt-1, Alt-2, and Alt-3 set
up to enter 'highlighted phrase'
tags.  For example, Alt-2 enters '
on the line, leaving it with the
cursor under the second colon and
the editor in insert mode.  I do
something similar for comments in C
- very handy and you can't forget to
close the comment!  On a somewhat
fancier scale, I have a 'paired
brackets' macro for C which enters a
left bracket, drops down a line,
indents two spaces, enters a right
bracket, inserts a blank line above,
and leaves the cursor properly
indented.  Even this isn't quite as
fancy as you can get - the standard
key assignment to turn on 'input
mode' actually redefines the
'return' to incorporate the
operations of adding a blank line
and matching the indent above.

OK, you say, sounds pretty good.  Is
there anything about this editor you
don't like?  Sure.  Top of the list
has to do with tab characters -
assuming the ANSI standard of a tab
stop every 8 spaces - to save space.
Not a bad idea if you are going to a
compiler, but a lot of things tend
to gag on the tab characters.  The
compression can be overridden, but
since it is the last operand in the
command, it is only at the expense
of typing the name of the file each
time you do a file.  A second
problem which doesn't strike
everyday is that when you have
overflowed to a 'spill file' things
sometimes get very slow.  In
particular, a 'file' or a 'save'
from a spill file is a
get-up-and-walk-around proposition.
Finally, it is worth noting that the
key definition macro facility has
all of its sophistication invested
in high-powered functions (like
'move the cursor under the first
non-blank character of the line
above') and has no looping, testing,
or parameter passing capability.
(If it did, it would be possible to
redefine a key to fix problem #1.)
All in all, I'm not complaining.

On to the bottom line, then:  Should
you or shouldn't you?  I think you
should!  Anyone who ventures beyond
the fringes of BASIC and VisiCalc,
whether it be to program in
Assembler, Pascal, or C, to edit BAT
files or keep lists of things, to
format electronic mail (which needs
paragraph reflow but not
pagination), or wants to do
correspondence or documentation
using a text formatter will find
Personal Editor a friendly and
powerful workhorse. I have seen no
other editor for the PC which would
make me even take a second look.  I
recommend you check out Personal
Editor and get your DOS a 'right
hand man'.