back2roots/padua/padua.7z/padua/misc/dmemacro.lzh/Better.readme

Text File | 1988-05-28 | 9KB | 171 lines

   A couple of years ago, I saw a language-sensitive editor on a Sun
workstation which utilized source-code templates and input `gadgets' (or
Sun's analogue of them) to greatly simplify the task of writing code.  I
have searched for over a year now in hopes of finding an editor for the
Amiga which could offer me similar power: I finally found one.

   The newest version of Matt Dillon's editor, DME (FF #134), offers
enough power in its macro language to emulate the code-entry features of
professional-quality, language-sensitive editors.  I have written several
dozen DME macros which create source-code templates (e.g., if-else blocks,
case structures, etc.) in four languages: C, Pascal, Modula-2 and Fortran.
By typing one key (or key-combination) and entering the desired variable-
name or conditional-expression, the macro will type the necessary keywords
and punctuation to complete the template.  Indentation is preserved, blank
lines are used to separate templates, and comments are printed where
feasible. The macros are easily (?) alterable to your standards of white-
space allocation and comment-inclusion, and they execute with great speed.

   Because these macros are stored in individual files, they must be
sourced each time the desired template is to be written into the source-
code file.  Thus, it is best to store the files in a ram-disk; whatever
keys you use to invoke the templates should source the files in the
ram-disk for fast execution.  While it would be nice to avoid having to
store extra files in a ram-disk, most of these macros are longer than the
255 characters allowed in a single line of a macro file (except for the
Fortran macros, which could probably all be put into individual macros and
sourced when the editor is brought up).  Even so, the speed at which the
macros write to the screen is pleasantly swift (this from a competent
touch-typist with a short temper).

   To try out the demos, do the following: run the Initiator in the
InitializeDemos directory (copies necessary files to ram:); launch the
template files in each of the language subdirectories in the DME_macros
directory; when finished trying-out the macros, run the Terminator in the
TerminalizeDemos directory (deletes files created by the Initiator).

   Before running the Initiator, (or the Terminator) be certain that the
following commands are in your c: directory and are immediately accessible:
COPY, DELETE, ASSIGN and MAKEDIR. The Initiator (and Terminator) need these
commands to create and destroy the directories and files required by the
templates.

   The Initiator, the Terminator and the template files are actually docu-
ment files used to launch DME.    These files are kept in separate subdirec-
tories so that DME will source the (unique) .edrc files in those subdirec-
tories.  Though the .info files for each of the document icons supports
argument-passing via the ToolTypes, you can't specify the macro file to
source on startup.  I have tried this several times with both the DME .info
file and the .info files for the documents; while the window-resizing tools
are handled properly, the macro-file option is apparently ignored.

   Once you `edit' (launch) the template file in a language subdirectory,
you will find that the keys on the numeric keypad have been mapped to the
macros available for that language.  If you press one of those keys, you
will see a skeleton of the template appear (there are a couple of excep-
tions) and the editor will (usually) enter command-entry mode with an
initial prompt of either a left single-quote or else a left single-quote
followed by a space.  You should type in the variable name or conditional
expression appropriate for the template, followed by a right single-quote
or else a space and then a right single-quote if the initial prompt
contained a left single-quote followed by a space.  If you have any trou-
ble, just read the text in the template file for explanations and examples.

   If my keymap preferences are confusing to you, just click the close box
in the edit window (you may have to do it twice if the file has been
modified).  The keymap definitions are contained in the .edrc file in the
OtherMacros subdirectory (accessible via the CLI); the file .edrc.commented
explains the definitions briefly.  The Initiator copies .edrc into the
directory ram:MD, and it is the ram-based copy which is sourced by each of
the language templates.  By changing these keydefs, or replacing the file
with your own .edrc file, you can change the editing environment to one more
familiar.

   Finally, in case it isn't immediately obvious, these macros are in the
public domain.    I claim no rights to any of the macros, which means that
you may butcher them to your heart's desire.  Happy hacking!


                          Jerry Mack

            NEW (temporary) ADDRESS:  8912 North Lamar Blvd.
                          Apt. 237
                          Austin, TX   78753


   P.S.  Peruse my .edrc file for some neat extras: Mac-like selection,
     copying and deletion of text blocks using the mouse (I use two
     clipboards, but you can use more); TRUE delete and backspace
     macros and TRUE forward- and backward-word-delete macros (be sure
     to put the join.edrc macro in a ram-disk and change the path name
     in the source command in my .edrc file); search and replace macros
     which allow replacing words anywhere under the cursor (allowing
     you to search a file with the FIND command and selectively replace
     strings without having to explicitly reposition the cursor and
     execute a FINDR); macros for shifting and deleting columns of text
     within a block; and a logical mapping of various scrolling and
     file-repositioning commands to the cursor keys and the nearby
     shift- and alt-keys.

 P.P.S.  I know my backspace and delete macros seem confusing; however, I
     strived over two days to make them short enough to execute quickly
     while still handling ALL the (known) cases in which the JOIN
     command doesn't behave properly.  Everything in the macros is
     essential; if you don't like the way it's written, just use it and
     forget that it's there.  By the way, here are some of the problems
     you'll have to contend with when using JOIN in you macros:

        a) JOIN eats all blank characters to the left of the first
           printable character in the line below the cursor;
        b) JOIN eats all blank characters (but one) to the right of
           the last printable character in the line containing the
           cursor;
        c) if you explicitly print blanks at the end of the current
           line to replace those eaten in a) above (as I did), you must
           check whether the cursor is one or more than one column to
           the right of the last printable character in the current
           line (it behaves differently in the two cases);
        d) if the line below the cursor is the last line of the
           file, JOIN mistakenly puts the cursor on the penultimate
           line when it has completed the join, unless
        e) there are only two lines in a file, in which case the JOIN
           command will exit with an error (since it can' t mistakenly
           place the cursor on the penultimate line) meaning the
           remainder of any macro containing the JOIN command will be
           ignored and the macro execution will be terminated;
        f) several others which I managed to purge from my long-term
           memory (good riddance!).

     There are occasional side-effects when using the delete and back-
     space keys with wordwrap enabled.  Also, do not try to join
     together lines with a combined length greater than 250 characters,
     unless you don't mind the macro eating parts of your file.


 BEWARE: There is a bug with the ESCIMM command which requires that it
     be in the last line of a macro file.  If there are any lines in
     the macro file subsequent to the line containing the ESCIMM
     command, then the text in the subsequent lines is written to the
     command line (it leaves a big mess).  You may include multiple,
     explicit ESCIMM commands in the last line, but you may not include
     the ESCIMM command within loops (they don't execute at all,
     apparently).


 Things Which Would Have Made This a Lot Simpler (not that I'm complain-
 ing, Matt):

     1) String variables - using $scanf is awkward and extremely
        limited;
     2) Integer variables (and arithmetic) - would have been very
        useful for and   loops;
     3) ability to extend if blocks across multiple lines for
        legibility (I probably won't get this one...);
     4) multiple test-conditions in loops and if blocks;
     5) don't specify the disk name in the default tool of the .info
        file - it prevents sourcing of the .edrc file in the subdirec-
        tory in which the text file is located (a colon is sufficient);
     6) ability to specify default script-file in tooltypes of text-
        file's .info file;
     7) a replace (not find-and-replace) command - for searching through
        a file and replacing selective occurrences of a string;
     8) force scanf to halt when it processes a blank - e.g., if you
        specify %[~,] for the control-string, scanf will process the
        entire line if it doesn't contain a comma; alternatively, allow
        the specification of a blank in the control string (e.g. %[~ ]),
        as this gets around the above limitation while maintaining com-
        patibility with macros others will have written by now;
     9) allow ESCIMM to be used in multiple lines in a macro file as
        well as within loops;
    10) fewer bugs.