Tuning your Macros
Question: How are macros handled? Are they read from disk and interpreted
each time they're called, or is there some way to keep them in memory? I have a
macro that is assigned to the enter key, and so gets called quite frequently. I'd
like to make it as efficient as possible.
Answer from Arthur
Pool:
In the OS/2 operating system, there are several different ways a REXX program can
call a function coded in REXX, each of which has implications for both performance
and maintainability. These options are discussed (briefly) in the WARP REXX on-line
information (at least, in WARP Connect V3), which says (inter alia):
- ... internal labels take first precedence,
- then built-in functions,
- and finally external functions.
External functions and subroutines have a system-defined search order. REXX searches
for external functions in the following order:
- Functions that have been loaded into the macrospace for pre-order execution;
- Functions that are part of a function package;
- REXX functions in the current directory, with the current extension;
- REXX functions along environment PATH, with the current extension;
- REXX functions in the current directory, with the default extension;
- REXX functions along environment PATH, with the default extension;
- Functions that have been loaded into the macrospace for post-order execution.
In practice then, the options, and their implications, are:
- Include the source code for the function in the primary source file. This should
provide the best performance. However, if the function is to be called by more than
one `primary' REXX program, this approach is undesirable in that it requires duplication
of code, with consequent maintenance problems.
- Load the macro function into a REXX 'MacroSpace'. This can be achieved using the
'RexxAddMacro' call from 'C', or using the 'RxAddMacro' function provided in the
'RXU' utility package (I understand that WARP 4 (Merlin) provides a similar function
in the REXXUTIL package but I have no experience with that). This approach is more
or less equivalent to the `EXECLOAD' facility in VM/CMS. This approach should provide
performance somewhere between the preceding and following approaches. It does however
have some management costs:
- you have to explicitly load the function into the macrospace - if you don't, you'll
simply execute the copy from disk, which will be much slower;
- you have to also ensure that the macrospace copy is unloaded and reloaded whenever
the function's source file is modified - if you don't you'll be executing an out-of-date
copy.
As noted above, functions can be loaded in either of two ways:
- Loaded into the MacroSpace for pre-order execution (executed BEFORE disk-based
files) - this should produce better performance than using disk-based functions.
- Loaded into the MacroSpace for post-order execution (executed AFTER disk-based
files) - this should produce worse performance than using disk-based functions (below).
However, it is worthwhile to consider the meaning of `current extension' and `default
extension'. When a function is loaded into the MacroSpace, it can be loaded with
an extension (eg, `.CMD') or without an extension. In these tests, as the primary
REXX file had an extension of `.CMD', it appears that the `current extension' is
`.CMD'. We therefore measured the performance of functions loaded into the MacroSpace
(and called) with an extension of `.CMD' and also without an extension.
Note however that in general one would prefer to load functions without extension
so that they are equally accessible to REXX programs with any extension - whether
called from REXX command files (.CMD), THE macros (.THE), or from other environments.
It's also cumbersome to have to specify the extension when invoking the macro.
We measured 4 sub-cases:
[2a] MacroSpace function, pre-order, .CMD extension;
[2b] MacroSpace function, pre-order, no extension;
[2c] MacroSpace function, post-order, .CMD extension;
[2d] MacroSpace function, post-order, no extension;
- Leave the source code as a separate file, which is invoked anew for each call
to the function. Although ideal in terms of maintenance, this approach will not
produce good performance. In practice, disk caching will reduce the impact of all
function calls after the first.
Also, the performance will be affected by whether the source file is in the current
directory, or how far the system has to search along the PATH string before it finds
the source file.
We therefore test these sub-categories:
[3a] source file in the CURRENT directory;
[3b] source file in a directory at the START of the PATH string.
[3c] source file in a directory at the END of the PATH string.
[3d] source file in a directory at the END of the PATH string, without
EAs.
See below for the rationale for test [3d].
Testresults:
Following are some measurements of elapsed time (in seconds) for 255 function calls
using these various approaches.
[C:\Usr\AFP\SW\Testing]REXX_Function_Call_Performance 255
[1]
|
function in the source program: |
0.88 |
[2a] |
MacroSpace function, pre-order, .CMD extension: |
2.06 |
[2b] |
MacroSpace function, pre-order, no extension: |
2.13 |
[2c] |
MacroSpace function, post-order, .CMD extension: |
91.09 |
[2d] |
MacroSpace function, post-order, no extension: |
180.87 |
[3a] |
function in an external source file - CURRENT directory: |
10.28 |
[3b] |
function in an external source file - START of PATH: |
12.66 |
[3c] |
function in an external source file - END of PATH: |
55.25 |
[3d] |
function in an external source file - END of PATH, no EAs: |
42.12 |
[C:\Usr\AFP\SW\Testing]
Notes:
- The function used was:
REXX_Function_Call_Performance_1:
return arg(1)**arg(1)
- These measurements were on a 80486-DX4 with OS/2 Warp Connect (Blue Box) with
no service pack applied, using (obviously) HPFS.
Conclusions:
- As expected, including the function in the primary source file was fastest.
- Loading the function in the MacroSpace for pre-order execution is slower than
including the function in the primary program, but much faster than invoking from
a disk file.
- Loading the function in the MacroSpace with an extension of `.CMD' is faster than
loading without any extension, most notably when loaded for post-order execution,
presumably because the first search is for macros with a `.CMD' extension.
Note however that to achieve this performance, the extension must be specified both
when the file is loaded and when the function is invoked - somewhat cumbersome,
and probably of marginal benefit in the case of pre-order execution except in the
most extreme cases.
- When loading automatically from a disk file, the position of the function's source
file in the PATH string can have a significant effect on performance - and the presence
of network drives in the PATH string is likely to exacerbate the effect.
- Loading in the MacroSpace for post-order execution is very slow. This slow performance
can be partly explained because the system searches every directory in the search
path (twice if the function is loaded without any extension), fails to find the
function as an separate external file, and then finally looks in the MacroSpace
(where it finds the function).
- Even allowing for the preceding item, note that the performance of functions loaded
in the MacroSpace for post-order execution is much slower in all cases than those
loaded from disk (even when the source file's directory is at the END of the PATH
string. Why is this?
I thought that perhaps it was because the version loaded into the MacroSpace does
not include the semi-compiled version which REXX normally stores in the Extended
Attributes (EAs), but test [3d] shows that this alone does not explain the poor
performance of tests [2c] and [2d].
- Test [3d] (see above) strips the EAs from the function's source file and makes
it read-only (which prevents REXX from attaching the semi-compiled form to the source
file) to compare the performance of an external source file without the benefit
of the semi-compiled form. Surprisingly, this version is faster than test [3c]!
Unlikely though it seems, the semi-compiled form appears to be of no benefit in
this test! Perhaps because the external function is quite small and relatively simple,
the additional overhead of accessing and loading the EAs outweighs the benefit of
the semi-compiled form?
In any case, the poor performance of tests [2c] and [2d] remains a puzzle.
- Loading in the MacroSpace for pre-order execution therefore appears to be generally
a good compromise - fairly good performance, easy to maintain, but has some management
overheads.
Files used:
C:\Usr\AFP\SW\Testing\REXX_Function_Call_Performance.cmd
C:\Usr\AFP\SW\Testing\REXX_Function_Call_Performance_2.cmd
- Download:
-
Test scripts: afp_rx01.zip (7.503 bytes)
-
Necessary libraries: rexxutil.dll (comes with OS/2) and rxu.dll, rexxutil.zip (contains
further documentation and samples):
-
from Hobbes at NMSU: rxu19.zip
01 December 1995, rexxutil.zip 31 January 1995 [file:11 July 1993], rxu1a.zip 8
May 1996
History:
- Sent to THElist 1998-03-16
- Updated copy sent to THElist 1998-08-03
Additional notes:
by Franz-Josef Wirtz
For REXX scripts (and THE macros) on the OS/2-platform so called extended
attributes (EAs) store the token image from a REXX-macro after
its first execution. The EAs are saved accompanying the original file and managed
by the operating system. Thus, subsequent calls can use the tokenized image and
eventually load and execute a little bit faster then (see result 3d and conclusion
7). I don't know, wether other REXX implementations use a similar mechanism.
A slight modified test script gave on my machine (P133 with Warp4 and ObjectRexx)
the following results (the second figure is the factor compared to the first result):
[1]
|
function in the source program: |
0.12 > 1
|
[2a] |
MacroSpace function, pre-order, .CMD extension: |
0.43 > 4
|
[2b] |
MacroSpace function, pre-order, no extension: |
0.44 > 4
|
[2c] |
MacroSpace function, post-order, .CMD extension: |
4.28 > 36
|
[2d] |
MacroSpace function, post-order, no extension: |
10.66 > 89
|
[3a] |
function in an external source file - CURRENT directory: |
1.78 > 15
|
[3b] |
function in an external source file - START of PATH: |
2.16 > 18
|
[3c] |
function in an external source file - END of PATH: |
5.09 > 42
|
[3d] |
function in an external source file - END of PATH, no EAs: |
6.06 > 51
|
Back to
Table of Content
Converting KEDIT-macro-library (.kml)
- Author:
-
Agustin Martin Domingo
- Download:
-
kml2the.zip (2897 bytes)
- Restriction:
-
Requires a c-compiler.
- Description:
-
Since THE does not support macro librarys you have to put each macro into a separate
.the-file. Here is a small utility for an automatic conversion. Thus, when you use
KEDIT besides THE you only have to maintain
the KEDIT-macro library. Nonetheless, you can't use REXX-variables across several
macros this way, since the separated macro files don't have any relation to each
other. They are loaded and executed each time they are called and unloaded immediatly
after completion. If you need to communicate between macros, you may use environment
variables for this job (with the value REXX function) or make use of the
new editv command.
Another restriction may be, that within KEDIT macros you can't use select-when-otherwise-end
constructs as in REXX (still true?), since KEDIT only implements a subset of REXX.
- License:
-
GNU General Public License
Back to
Table of Content
Porting XEDIT-macros
By Mark Hessling
I have been hearing from a few of you regarding the porting of XEDIT macros to THE,
and thought I would suggest a couple of things that may make your life easier in
the future.
While most XEDIT users will use THE in full XEDIT compatibility mode, I would strongly
suggest that macros be written in THE compatibility mode.
The reason for this is that the behaviour of THE wrt movement of focus and current
lines, movement of cursor
etc.
in various commands in THE compatibility mode is stable and unlikely to change,
whereas in XEDIT compatibility mode, it is likely that behaviour will change as
I fix it. The end result is that your macros will break :-(
You should add an EXTRACT of COMPAT at the beginning of
the macro, followed by a SET COMPAT THE THE THE, and when the macro
finishes, restore the settings saved.
Back to
Table of Content
Writing OS-portable Macros
Some aspects need to be considerd when macros should be usable on various operating
systems.
- REXX-interpreters differ [stream(), directory(), index()
],
- command shells differ [handling of environment variables at OS-level or with
value(), adressing the OS (
address cmd vs. address system),
names of external or internal utilities like dir-command (OS/2 <>
WIN32) vs. ls -utility],
- file i/o differs,
- file name constitution differs [drive, dir separator, long filenames, file type,
allowed chars],
- available utilities vary [e.g. grep, ls, indent, fmt, ispell, rxqueue, etags
],
- available keys differ [only few keys with OS=UNIX, e.g. no ALT-keys],
- access to mouse differs [no mouse on OS=OS2 or OS=UNIX].
- some THE-stuff vary [Soft Label Keys, Color...]
Although this seems to make porting awkward, in real life it's not
that problem.
You should try it when the time comes to it and look at the forebears. You're not
the first :-), so now it's a bit easier.
Back to
Table of Content
Finding Errors in Your Macros
Question:
Is there a facility for tracing the operation (or, more aptly, the non-operation)
of a THE macro which I am developing?
Answer:
This is a difficult task indeed. ;-)
Solution 1: Use REXX TRACE
You can use the REXX-instruction
TRACE to give various output, but this will either go to a so called
pseudo file within the ring of THE-files, called REXX.$$$ or be
displayed in an own window. The disadvantage on this is, that you have to wait until
your macro is completed, and then analyse the output. When you call your macro via
MACRO ? somefailingmacro somefancyarguments
you can debug the macro interactively, if trace is set appropriately. For lengthy
output it is recommended to use SET REXXOUTPUT FILE 1000 so that you
can page through the output (the number denotes the maximum size, in case you have
infinit loops ;-).
On Linux with XCurses-THE this REXX-TRACE output will go to stderr which
is much more useful. You can redirect it to a file (the testfile.tst 2>the.log)
and follow this file synchonously with tail -f the.log in another terminal
window.
I don't know wether there exists a parser which can display this output in an useful
way. Any hints welcome. Maybe, the RxD-tool could be misused for that
in some way, if the sources would be available (RxD is an interactive OS/2-Presentation
Manager source level debugger for REXX programs by Patrick Mueller, available as
IBM-EWS for free [content,
rxd.zip download 150k
at leo , many hobbes mirrors have it too])?
Solution 2a: Write to Message Line
A quick and dirty method is to to use the THE-command MSG to write
something to the message line(s). When you're done you have to remove or comment
out these lines.
Solution 2b: Write to Logfile
A slightly better way is to use another macro for doing some logging into a separate
file. I use the following:
/* fwlog -- */
logfile = "fw.log"
parse arg filename msg
call lineout logfile, date() time() filename":" msg
call stream logfile, "command", "close"
exit
This macro closes the logging stream immediatly, thus you will see the output
immediatly, e.g. when you use tail -f fw.log .
You would call this like
/* some damned macro.the */
wantlog = 1
myname = "some_damned_macro.the" /* you could use 'parse source' either...*/
somefancybuterroneousstuff
mymsg = "somevar="somevar
if (wantlog) then 'macro fwlog' myname mymsg
somemorefancystuff
exit
So, you fill up your macro with debugging code. At least, you can turn the
output on or off.
Solution 3: Use THE-trace
You can compile THE with some options to produce its own trace output. I never did
this and I think it's more for those who want to debug THE itself.
Solution 4: Use REXX SIGNAL
You can trap REXX exceptions. A very helpful one is the signal on novalue.
This might serve as a template for using this feature:
/* somefancymacro -- */
signal on failure name _FAILURE_EXIT
signal on halt name _HALT_EXIT
signal on syntax name _SYNTAX_EXIT
signal on novalue name _NOVALUE_EXIT
out.0 = 0
trace off
myname = 'somefancymacro'
myfilename = myname'.the'
logfile = "fw.log"
lotsoffancystuff
signal _CLEANUP
exit /*just in case*/
/*********************** signal targets **************************/
_SYNTAX_EXIT:
syn_rc = rc
trace off
os = version.3()
if (os == "OS2") then
do
rcinfo = "REX"||right( syn_RC, 4, '0')
drop out.
rc = run_os( 'helpmsg 'rcinfo, , 'out.')
end
i_line = out.0 + 1
out.0 = i_line
out.i_line = 'Syntaxerror no. 'syn_rc' at line 'SIGL':'
i_line = out.0 + 1
out.0 = i_line
out.i_line = sourceline( SIGL)
signal _CLEANUP
exit /* just in case */
_FAILURE_EXIT:
trace off
i_line = out.0 + 1
out.0 = i_line
out.i_line = 'General failure at line 'SIGL
i_line = out.0 + 1
out.0 = i_line
out.i_line = sourceline( SIGL)
signal _CLEANUP
exit /* just in case */
_HALT_EXIT:
trace off
i_line = out.0 + 1
out.0 = i_line
out.i_line = 'Halt condition (^C) met at line 'SIGL
i_line = out.0 + 1
out.0 = i_line
out.i_line = sourceline( SIGL)
signal _CLEANUP
exit /* just in case */
_NOVALUE_EXIT:
trace off
i_line = out.0 + 1
out.0 = i_line
out.i_line = 'Used variable "'condition("D")'"without a value at line 'SIGL
i_line = out.0 + 1
out.0 = i_line
out.i_line = sourceline( SIGL)
signal _CLEANUP
exit /* just in case */
_CLEANUP:
trace off
if (out.0 = 0) then
exit
'set msgmode on'
'extract /msgline/'
'set msgline on -1 'out.0' overlay'
do i_out = 1 to out.0
'msg 'out.i_out
end
'set msgline 'msgline.1 msgline.2 msgline.3 msgline.4
if wantlog then
do
do i_out = 1 to out.0
call lineout logfile,date() time() out.i_out
end
call stream logfile, "command", "close"
end
exit
/* the end of somefancymacro.the */
When encountering the syntax exception this macros would call the OS/2-utility
helpmsg for details on the error, and display this too in the msg area
and the log file.
Note: instead of terminating your macro with exit, you would use
signal _CLEANUP. Usually, that part is where you can handle other cleanup
stuff which should be processed in any case (removing bak files or so). If you don't
have something to process there, it would be no problem not using signal _CLEANUP
but exit ;-)
By the way: I use an underscore as the first char of the label, just for
convention, to distinguish this from a procedures name. Usually, with signal
you won't be able to come back to the place where signal is triggered. You should
not misuse the signal instruction in place of a goto (which
does not exist in REXX).
Solution 5: Language Sensitive Editor
You can use a language sensitive editor which at least does not allow to insert
unbalanced do..end or parentheses within call instructions and alike.
Syntax highlighting is also a helpful feature which can enlight the structure and
functionality of your macros. (I use emacs with
rexx-mode and an own rexx-highlight-mode for this. :-O )
Solution 6: Macro Analyzing Tools
You can use tools for analyzing REXX-macros. Besides formatting and cross referencing
the macro some can check for simple syntax errors. See coding
suggestions.
Recommended Further Readings
There are some valuable hints on common problems with REXX:
Typical THE Pitfall
With THE, a valuable source of error conditions is the mismatch of the place of
action between what you're thinking and where THE is working. You have to be very
careful on beeing sure, what the current line is and what the focus line
is and where the cursor is. If cursor is within the file area, the
focus is at the same place and most commands act there. When cursor is at command
line, the focus is where cursor was, but action happens at current line.
E.g. locate moves the current line to the target (if it can be found),
but the focus line remains at the place where it was.
Some commands move the cursor from file area to command line implicitly. Note: with
sos makecurr you can make the focus line the current line (e.g. the file
will scroll), and with sos current you can move the cursor to the current
line.
This becomes even more complicated depending on the compatibility mode you use.
You're strongly recommended to use
set compat = THE =
where = is the mode for look and keys you like. (See
Mark's note. )
Back to
Table of Content
Sharing Your Macros
It would be great to see your macros in this list too:-) Thus others could make
use of them. Also macros from different people would enlight the versatility and
extensibility of THE. Another point is that each macro can show, how a distinct
problem can be solved an serve as an example to encourage others to make their first
steps.
Don't be afraid to receive annoying flames from people trying to use your macros.
The users of THE are a quite friendly community and know of the problems of
writing and sharing code while dipping into many
pitfalls . As they use THE, they like to share with others as they know
that only cooperation will improve the worlds face:-).
You can send any contributions as a posting to THELIST (in case you are already
subscribed to that mailing list). Another way would be to email the macro(s) to
Franz-Josef Wirtz as the current maintainer of this index file.
Some things you might consider on deploying your code:
- Accompany the macro with enough information to
- identify yourself (e.g. email address),
- show your licensing intention (e.g. public domain, GNU Public License, shareware
or whatever else),
- show your maintaining intention (do you want to get asked for making improvements
or add improvements others wrote...?),
- some info on the version,
- tell the purpose,
- the usage instruction
- and any restrictions/ requirements of the macro.
When it's one file, these infos should be placed in the header, when you pack a
little zip, a separate README would be a better choice;
- When you pack several files together, you might worry about the naming of the
package. You might think of the following naming convention:
thefwfold27a.zip where
- the: for use with THE
- fw: initials of the author
- 27: THE version already supported
- a: your distribution counter
- zip: standard ZIP-archiv.
You might also consult KEDIT's guide
for user contributions for further tips.
Back to
Table of Content
Coding Conventions
There are several styles around for coding REXX according to
To follow one of these styles would improve the readability of your macros to others.
Eventually you might look at
GNU coding standards for further guidance. Although it's a bit c
orientated, the general concepts are also valuable for REXX.
There has been a REXX formatter and cross referencer available (REXXREF3)
from Stephen Ferg, but
the last officially released version needs Personal
REXX for DOS (by Quercus Systems, but see below for a solution without Personal
REXX). The accompanying documents say, that intermediate versions of this were KEDIT
macros. Maybe someone still owns these macros? This formatter / referencer can do
also some error checking.
I wrote some REXX-scripts to simulate Personal REXX functions used within REXXREF3
and adopted it so that it can work on OS/2 and does no longer depend on the sort
utility "lsrtos2" which is shareware. Instead it can use THE for this. You can get
these scripts free upon request from me (Franz-Josef Wirtz).
Finally, Stephen Ferg is working on a more portable version
which will work on OS/2 and linux as well. You may contact him to see its progress.
Another similar (non-free, 15$ shareware) tool is
REXX Code Formatter/2 (RCF/2) (download
986k from hobbes), running on OS/2 Warp 3.0.
You can map REXX program function and subroutine references with
CodeAnalyzer002.zip (OS/2) by Doug Rickman.
Casey Bralla wrote a freeware
REXX Command Formatter - Indenter, which formats OS/2 REXX command files to
indent Do / End structures.
Neil Hancock collected lots of general
style guidelines for REXX-scripts.
Some other guidelines might be:
- Avoid abbreviated THE commands so the command name talks.
- Don't omit the set or macro keyword so it's clearer what is
called.
- Avoid multiple statements in one line, so the logic becomes clearer.
- Introduce names for line targets with an underscore to differentiate to procedures.
- Put the macro name followed by at least two dashes into the first comment line,
so that the rxtag -Utility can respect macro calls.
- Break and continue long lines with a
"," (comma) at the very end
of each line, break long strings with the concatening operator "||"
or " " (blank).
- Make freely use of blanks between variables, operators, arguments...
- More to be added...
There is a tutorial from Toby Thurston
(Toby_Thurston@europe.notes.pw.com) on REXX-macros for the
X2 editor by Blair W. Thompson (bwt@interlog.com)
available at that webpage (ttxmacs.htm). This tutorial also covers some general
guidelines for writing macros which are applicable to THE-macros as well. In brief,
he pointed out the following:
- respect current word, line, marks or regions up to a passed target,
- respect current cursor position and restore it if appropriate,
- respect users settings (e.g. insert mode, word delimiters),
- restore settings if changed,
- respect national conventions from the OS (e.g. date time style, decimal point
indicator and alike),
- allow with variables at the top an easy translation of fixed strings,
- generalize common stuff in procedure macros called by others,
- make use of general available functions (e.g. ispell, grep, sort) with an interface
instead of implementing them anew in your macro,
- think of a way of undoing the effect of your macro,
- avoid the assignment of a macro which can do much harm to an easily accessible
key to prevent a call by accident,
- think of giving help on a macro call which needs arguments when no one or a question
mark is passed,
- try to be flexible in parsing arguments.
Back to
Table of Content
Other Sources of Information on Writing Macros
If you are not familiar in writing macros the first you need is some knowledge over
the functions and commands brought to you by THE. You can find information on this
in the documents accompanying THE or it's master
XEDIT/KEDIT. Just start at the functions suitable for doing the job you wanted
to do in an automated way. You can try out the commands from the command line of
THE. There's a macro available (recordit) to record your
entered commands as a macro.
When you know, what you want to do with THE commands, you should then inform yourself
about REXX, since THE macros are written in REXX. REXX embeds your THE commands
into a script, which allows you to control the flow of commands. You can impose
conditions, various kinds of loops and much more. REXX itself offers also a lot
of useful functions, especially for dealing with strings. Thus, when THE does not
have a string processing command, probably REXX has it. It is very likely, that
the combination of REXX's and THE's commands and functions offer you all you need
to process any text. THE manages the display and storage and moving around, and
REXX manages the manipulation.
The REXX language passes any unknown stuff to the environment. A THE-macro is a
REXX-script where it's environment is THE. THE checks all passed stuff against it's
own extension (functions, commands, variables) and finally passes still unknown
stuff to the environment of THE, which usually is the operating system (command
interpreter, shell). This way, you have unlimited power for working on your text,
since for example you can reformat text even with tools available on operating systems
base like sort, grep, ispell or even
awk and alike. That way, THE-macros are scripts, which glue together many
powerful ways for processing text.
Sources of information and examples for giving your macro the desired structure
with REXX can be found at the following places:
- XEDIT Reference
- XEDIT Tutorials
- REXX Reference
- REXX Tutorials
- REXX Tips
- Editor related stuff
- Nikolai Bezroukov: commented
collection of very useful links for XEDIT-like editors (called eastern orthodox
editors). You can either download various types of macros from there or even
follow to online references and guides of IBM's XEDIT or Rex Swain's comparative
reference material for XEDIT and KEDIT and more.
- Toby Thurston: tutorial
on REXX-macros for the X2 editor
by Blair W. Thompson. Many example macros are available there too.
- KEDIT Macro Library
The extensions of THE which are typical for text manipulation are
documented in an own extensive HTML or plain text document. This
online reference is enclosed in the distribution of THE (or can be generated
from the source-distribution). The
appendices 5 and 6
are especially useful for macro writers. Also within its distribution is a small
set of macros, which enlight some interesting features. You should not miss these.
Note: Check out http://www.gut-wirtz.de/THE/rearranged/index.htm
for an alternative structure of the HTML-manual.
Back to
Table of Content
Coding THE-macros With Other Editors Than THE
Sometimes it's desired to have an editor at hand, which can correct a macro just
changed and disallowing to edit files properly with THE;-). Roger Nelson
gives an overview over nearly
all available editors.
emacs there is a powerful REXX-mode available, written in 1994 by
Scott Maxwell (email address probably defunct), archie or
ftpsearch for rexxmd or look at sites hosting emacs contributions,
it's not part of the standard emacs distribution; there's another, though less powerful
rexx-mode from
Anders Lindgren, written
in 1993 and part of XEmacs, waiting for a new maintainer; finally, a third approach
on writing a
rexx-mode (rx-mode.zip) had been started by Espen Skoglung and
Ralf Grohmann
around 1993/1994, thus intermediate between Scott's and Anders' mode).
There is also a highlight mode for Scott Maxwell's mode to have the code
in fancy colors (from Franz-Josef Wirtz).
The FW-macros contain also a file (rxtag.cmd) to utilize
etags for creating TAG files on THE-macros. With such a TAG file you can
quickly look up the called macro or procedure.
Just for your interest, there is another free editor with REXX as it's scripting
language available for several platforms:
X2 editor by Blair W. Thompson (bwt@interlog.com),
a programmers text mode / X-windows editor with keyword highlighting, tag, completion
etc, derived from Tim Baldwin's XE sample editor, with influencences from
XEDIT as well (e.g. all command and many others). At it's homepage
there are also many macros available. Maybe these might inspire you too. When looking
at these macros you will feel yourself quite familiar to what you already know from
THE:-)
