Re: merits of Code400 was RE: Coloring the RPG code

Rick,

>I don't use tabs in SEU.  but I don't really need to.    I rarely write a
>new line of code - I mostly just copy and modify.

But you're in this habit as a workaround simply because SEU cannot intelligently
control the cursor in the same manner as a PC-based editor.  You're doing it in
part to get lines with the C in column 6, and text in some of the other fields
so you can use ctrl-left/right.

>I then use Client Access alt-right or left to get where I want. (next/prev 
>field).

I assume you mean ctrl instead of alt, or else you like to use unusual key
mappings.  But it is *not* next/prev field -- it is next/prev "word".  And
therein lies a *big* difference.  A "word" for purposes of ctrl-right/left needs
white space.  So for example in RPG III, if the opcode takes all 5 positions it
will not stop at factor 2.  Neither will it stop if there doesn't happen to be
text there.

Instead of copying source lines to modify, you may want to try using SEU's
support for a "skeleton" line and a TABS line.  If you're going to use SEU, then
you may as well learn how to make the most of it.

However, an intelligent editor is much smarter about a "word" than simple
whitespace.  And it can automatically vary its definition depending on context
and source type.  So for example, with a statement like:

        Eval result=%scan(search:array(index):start)

it knows to stop on the %, the s of search, the a of array, the i of index, and
the s of start.  Even though there is no whitespace.

(For the record, I normally leave a space around each "word" anyway because I
think it is easier to read.  But also because it is easier to navigate when
forced to revert to SEU and only have the ability to stop after whitespace.)

You also get different on-the-fly coloring for keywords vs constants vs
variables, etc.  This not only aids readability, but makes it painfully obvious
as you are typing if you forget a closing quote or whatever, because the color
is wrong for subsequent text.

>the thing I like the most about seu is that I never have to reach for the
>mouse.  unless I want to :).

I rarely use the mouse while editing either -- there are so many keyboard
shortcuts to do all kinds of wonderful things that I rarely choose to move my
hands off the keys.  Shortcuts are faster.

They are also much faster than tabbing to the line command area, or pressing F10
and entering a command.

>>I don't consider color coding to be a feature although my color vision
>works
>>fine. <g>
>
>I like a little color, but it's not really necessary.

It is not "necessary", but it is a big aid to readability.  This is true of both
column sensitive data and also free format.  And I don't just mean changing the
color of complete lines, particularly comments, by inserting attributes in col
5.  Having fields in adjacent columns be different colors helps to "read" it at
a glance, and to know as you are typing if you are in the correct place.  (Of
course, you could also enable a "shadow cursor" on a ruler line at the top of
the window to see your current place in the spec too -- and the ruler line will
automatically change depending on context -- not just the type of statement on
the first line on the display.)

>my "sequencer"
>program (you know - b1, x1, e1, in the margins) turns comments white when I
>can't see the forest for the trees.

But why not let the editor show you that -- instantly and dynamically -- even as
you make changes to the source?  Unlike a utility which must be rerun, it is
never out of sync with the source no matter what modifications you have made.

One press of a keyboard shortcut and I can instantly highlight an entire block,
or jump to the matching begin/end statement.  Regardless of the number of levels
nested inside it or how far away it is.  And then if the code calls a subroutine
or a subprocedure, another shortcut key and I'm instantly transfered to the
start of the routine to review it.  No need to press F10 and a find command.
I'm looking at the routine by the time your cursor rests on the top line.
Peruse the routine (and maybe jump to other routines), then press a couple of
keys and I'm right back where I was.  Without the need to remember any line
numbers or other silly crutches.

>I tried to play around with CODE, and Picante Software's version (I don't
>remember the name - I think Codewrite bought it several years ago).

I'm probably one of the few die-hard Flex Edit users left who hasn't switched to
CODE.  (I'm probably also one of the few who upgraded Flex to use the newer
engines for Codewright -- I'm running Codewright 6.5b as a base.)

But for the record, Codewright did not buy Flex Edit.  Picante licensed the
Codewright engine as the base for the Windows version of Flex, and wrote
extensions to make it integrate with the 400 and add language specific handling
for RPG, DDS, CL, etc.  Picante later sold that to Aldon, and I believe Aldon
has resold it again but it is no longer marketed as such.

>there aren't enough features to make me force myself to switch.

In all seriousness, then you need to look at the features again.  The problem
most people have with something like CODE or Flex Edit or CodeStudio, is that
they try to use it just like SEU.  They don't learn to take advantage of the
paradigm shift you can make in how you code.

>It would probably take at least a few weeks to
>become comfortable with CODE, and months before I would learn all the
>whistles and bells well enough that I would become equally productive as I
>am in seu.

There is no reason for that to be true.  You should be able to match the
productivity of SEU (or lack thereof <g>) within a day or two at the outside
provided you have any experience on the PC using some Integrated Development
Environment.  Even without IDE experience it shouldn't take more than a couple
of days to match SEU's productivity.

Granted, you won't know all the bells & whistles for a long time.  But you
should be *more* productive soon anyway, and it will only get better as you
learn more of the features.

Besides, if you're not using skeleton lines, TABS support and other such line
commands, you aren't even using SEU to its potential. <g>

Doug