winalski@psw.DEC.COM (Paul S. Winalski 12-Aug-1987 0827) (08/12/87)
The EDT keypad was chosen for LSE during version 1 development for the following
reasons:
- EVE did not exist yet. It was developed in parallel with LSE. At the time,
EDT was the standard editor for VMS. Therefore, our existing customer base
was familiar with EDT, and we chose that keypad to be compatible with what
the majority of our existing customers were used to.
- EVE was developed using an iterative design refinement with useability testing
technique by the Human Factors research group in DEC software engineering.
They started with no preconceived notion of what the interface should look
like and experimented with many designs. There was no commitment at any time
until very late in the game that what they came up with would actually ship
with VMS. LSE was from the beginning a product with a committed (and
agressive) development schedule. We could not base our user interface on
something that wasn't specified and in fact might never materialize.
- None of us who were on the LSE V1 team liked what the EVE group came up with.
While EVE is a fine user interface for novices, I find it functionally
deficient and not suitable for experienced users (and experienced programmers
are the primary audience for LSE). Admittedly, this rapidly degenerates into
a religious argument. Nonetheless, our own personal biases meant that we
did not lose any sleep over our lack of EVE compatibility.
So that is why the default keypad is the EDT keypad. In LSE version 2, you
can change to the EVE keypad bindings with the LSE command
SET MODE KEYPAD=EVE. Of course, as always, you can define whatever keypad
bindings you want using the DEFINE KEY command or TPU code.
Regarding the other points you bring up:
- duplicate keys (FIND = PF3), (PREV_SCREEN = GOLD-PF4): these are standard
EDT bindings for the LK201 keypad.
- differences from standard DCL keys (CTRL/A, CTRL/E): alias definition and
template expansion are very necessary functions in LSE. One might say that
they are the whole reason for LSE's existence. We wanted to bind them to
places that would be on the main keypad array (to avoid having to lift the
hands off the keyboard), were mnemonic, and made the least disturbance of
EDT's keyboard CTRL definitions. Compatibility with EVE, as previously
mentioned, was not a consideration. You are letting your EVE bias show.
- the margin setting commands are designed to make programming easier, something
that was not a design factor in either EVE or EDT, but which is central to
the purpose of LSE.
- LEARN mode: LSE does not provide standard keypad definitions or commands
for this, but it is trivial to do in TPU:
DEFINE_KEY('LEARN_BEGIN(EXACT), F7);
DEFINE_KEY('LEARN_BEGIN(NOEXACT), KEY_NAME(F7, SHIFT_KEY));
DEFINE_KEY('X:=LEARN_END; DEFINE_KEY(X, F14)', F8);
These three TPU statements set up the following keypad bindings:
F7 starts a learn sequence in EXACT mode
GOLD-F7 starts a learn sequence in NOEXACT mode
F8 terminates a learn sequence and binds the sequence to F14
The problem of layering LSE on EVE (or EVE on LSE) is not a trivial one, and
doing a complete and proper job is more than a few weekend's work. What we'd
all like to see is a LSE section file that has all of EVE's TPU functions in
it so that EVE users who have extended EVE can run the same extensions on LSE.
Although there are no commitments to provide this for any future release of
LSE at this time, we are aware of the problem.
--PSW (LSE Version 1 developer)