Re: Large screen monitor

Rob,

>Such as (apart from graphical features)?

The GUI part doesn't matter so much with a text editor.  I was a happy
user of Flex/Edit for DOS before I ever ran Windoze.

The biggest disadvantage of a block-mode interface over a workstation
(in terms of inherent differences) is that you can't be context
sensitive at the keystroke level.  For example, my tab key and backtab
key really work, and are dynamically sensitive to the type of line
containing the cursor.  Color coding is immediate and automatic; eg,
keyword values appear in a different color than keywords, or
column-sensitive stuff has different colors for adjoining fields.  As
you move the cursor, the ruler line at the top of the window changes
to match the source line containing the cursor.  And for calcs, you
get a different ruler line for each opcode, with each field labeled
for what it does for *that* opcode.

Undo/redo really works, to an infinite level.  It is *vastly*
different than F5=Refresh.  I can back up literally one keystroke at a
time, until back to the original state.  In Flex/Edit, it also will
undo cursor movement and virtually any other activity, such as global
replacements of text.  With CODE, I *think* it only will undo buffer
changes, not cursor movements.  I'd have to adjust to that, because I
sometimes use undo where I could use a bookmark -- as a method to
quickly return to a given point after looking at something else.

Another feature I suspect we'll see in editors like CODE but not SEU
is word completion and function tooltips.  Word completion is where it
offers to complete a variable or function name based on your first few
letters -- much like Quicken does with a Payee name.  Now that we're
all using longer variable names and meaningful procedure names (arent
we??) this has more value than 6 char names.

Function tooltips are balloons which float over your cursor as soon as
you type the leading "(" of a function or BIF.  It displays the list
of arguments based on the BIF or prototype, and highlights in bold the
one you are currently keying.  As soon as you type the closing ), the
tooltip disappears.  Stuff like this happens today with other
languages and editors.  There is no reason we shouldn't have the same
capabilities.

Think about it.  Name your service procedures right and you can nearly
forget about help files or documentation crib sheets.  Type a % and
see all the BIF names, or "rtv"see all your service procedures to
retrieve a value.  It can also be smart enough to not do anything
until it sees you pause longer before typing another character.  Pick
the right one, and then a tooltip appears listing the arguments, in
order.  Key the values, type the ) and keep on going.  Hoover the
mouse over an existing function to see its argument definitions.

I suppose a F4 prompt could throw up a window to select from, but
having the list sensitive to each keystroke as you type it is way more
convienent.  

Then there is the issue of performance.  I have a dedicated RISC
machine for development.  I'm the only user, so basically have all
160MB of memory at my disposal.  Response time in SEU is way better
than SEU at my client sites.  But it still can't match my PC editor,
which is virtually instanteous no matter how I jump or scroll.  Even
cursor movement is harder on a dumb terminal because you can't jump a
"word" at a time ala Ctrl-Left/Right.  You can do this with an
emulator and SEU, but now we're talking about a PC again.  A good
editor also has a better definition of a "word" for the sake of cursor
movement, and doesn't need whitespace but will recognize whatever you
configure for that language for delimiters, such as : or ( or
whatever.

>There is one copy of Code/400 on every PC that has a
>developer using it and PC's require constant attention.

PC's don't require constant attention unless you are constantly
installing software and getting into "DLL Hell", or you've never
gotten out of DLL Hell after a previous install of something.  Run NT
or W2K and quit playing with settings and they are much more stable
than you give them credit for.  I'm by no means saying it is on par
with OS/400 -- but constant attention is only required when you
constantly change the machine.

>I know that Code/400 has facilities not in SEU, but I (and others) don't want 
>to
>use a Windows based product and want the features added to SEU.

The features I talked about above were in relation to a block-mode
device vs keystroke sensitive logic.  Many other features are not as
reliant on real-time keystroke processing but are context sensitive,
for example:

 - Jump to a subroutine/subprocedure named under the cursor, and
optionally put it in a different window for concurrent work.  (When
not in a new wnidow, set an automatic bookmark to make it easy to
return to where you had been.)  This makes navigating programs
incredibly easy.  Sure you can press F10 and type F name x where x is
18 or 12 (rpg iv) or 8 (proc name), but by the time your finger is off
the F10 key I'm already looking at the new source

 - Jump to a matching end statement regardless of nest levels (or from
an end to a begining of a structure), or select an entire block with a
single key instead of having to find the start and end points.  As you
"desk-check" code, this lets you immediately branch to an end point to
follow program flow, regardless of whether or not it is visible and
regardless of intervening nest levels.

 - Collapse view to just lines containing field under the cursor (like
doing an exclude all then find of the word -- but where it only finds
occurences where the word is used as a field name, not within a
comment or whatever).  Plus the ability to expand just the lines
around a given occurence for inspection/edit.

Numerous other things aren't even context sensitive -- they are just
basic editing features.  For example:

 - Multiple windows to the *same* source member, all editable at the
same time, with changes in one obviously affecting the others (in real
time if visible).  One window on D-specs for adding/viewing variable
definitions, one on the program mainline or other area of interest,
others drilled down to various other positions.

 - Multiple different members open for edit (not browse) with copy and
paste or drag & drop between them.  This precludes using multiple
sessions, one per member.  It is more like F15, with an editible
lower-half of the screen.

 - File differencing for comparing versions, with color coded
highlighting, side-by-side synchronized scrolling, and the ability to
transfer changes*easily* or manual drag & drop.  You may consider this
the domain of a change management system, but my editor (Flex/Edit)
has it built-in.  I don't know if CODE does or not.

 - Regular expression search and replace for advanced pattern
matching.  Regex is something every unix person understands, but
probably not as many 400 folk.  The more you use it, the more you
appreciate its flexibility.

 - Collapsible compact mode. This is like doing an exclude all, then a
find of every BEGSR and procedure begin statement.  Select any line to
expand just the one routine, then be able to collapse it again.

 - Bookmarks to set return points to spots of interest.

 - Template expansion for code blocks with prompting for variables to
be inserted, and control over where the cursor ends after expansion

 - Macro support which is more than just keystroke playback, but more
like what VBA macros would allow in Word.  These need to be able to
manipulate the buffer, but not duplicate function already in SEU.  EG,
you should be able to cause a find or replace to occur, but using
SEU's find/replace support.  Then based on the success of the
operation, perform other operations.  

Some of these could be done in SEU with line commands or command line
actions, but most of them not with the current exit points.  You can't
make SEU go through a sequence of actions like even a simple macro
processor.  You can't issue a single action for that matter - like a
Find or Replace.  You can't even reposition the source for goodness
sake.  And you can't modify text outside the block or line containing
the command, so you can't make a simple command to act on the source
without having to mark the top and bottom statements then suffer the
overhead of copying the SEU work area to the qtemp user space, then
have SEU reload it.

The idea of user-defined SEU commands sounded great at first blush,
since I've been using extensible editors for a long time.  But the
implementation in SEU only touches the surface of what you'd need to
make it really extensible.

Doug

PS - I don't store my source on the PC either.  I keep it on the 400.
And I use PDM, with a user-defined option to edit it via the PC.  It
opens in my PC editor *faster* than SEU except for real small members,
which don't take much time with either method.

PPS - I realize I won't convert you, because your mind is made up.
But you asked why SEU's block-mode interface is inherently incapable
of matching a workstation-based editor.  It is not Windoze or a GUI
which enables this stuff -- I did it under DOS too.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---