Crunch CRiSP File Editor 6 - Manual (Page 9)

Page 9
→
Writing your own macros(pg. 9).
→
The .m language(pg. 90).
→
The crunch language(pg. 14).
Writing your own macros
Private macros can be loosely categorized into two types: small one-off macros which are used to make
some piece of functionality easier to use (e.g. mapping certain editing commands to special keystrokes), or
major projects in their own right. The entirety of the CRiSP product can be broken down into major
subsystems (Unix mail, the setup dialog boxes) or simple value-added services, such as capitalizing words,
repeating the last search.
The bits that go to make up CRiSP as a whole are structured in a way that has allowed CRiSP to evolve and
allow room for manoeuvre as future functionality is added. CRiSP and the macro environment is a bit like the
Microsoft Windows 3.x environment in that all the macros are co-operative. Most macros are independent of
one another but within the context of a file editor, the macros are all adding value to the software.
When you come to write your own macros, you will need to think and understand what you are trying to
achieve. For one-liner macros, there is little to think about and you can pretty much achieve what you want
once you understand the mechanics of CRiSP. If you are attempting to build a complex macro then it can be
useful to step back and think about what you want to achieve. Much of this is common sense and applies to
software development in general, but it is worth understanding the environment you are going to be
programming in. Much of this manual is devoted to explaining the technical concepts and issues in writing
your macros. This section is more concerned with taking a steady pass over the concept of macro writing.
There is nothing magic or special in writing macros to extend CRiSP for your own personal desire. There is
a great sense of achievement in mechanizing some tedious editor task which has frustrated you in the past.
So in a sense, customizing the editor can have its appeal.
One of the major goals of the CRiSP macros is an attempt to achieve an object-oriented structured design.
(The term 'object-oriented' is used in a loose sense). When writing a macro to achieve something it is
desirable to ensure that the macro you have does not interfere with any existing macro. Also, looking to the
future, you need to ensure that other newer macros cannot affect the functionality of your macros. For a
normal high-level programming language, once you have written a program, debugged and compiled it, that
is it. Nothing can affect the correct behaviour of that program.
With an interpretive environment like CRiSP you are not in control. Rather, it is like being a guest in
someone elses house - you have to obey the rules or else you will get into a muddle. If we consider that the
environment of CRiSP, the macros and the binary, is one giant program, then in effect what you are doing
when writing your own macro is customizing the existing behaviour - you are interfering with the existing
code. The problems that can strike firstly is accidentally reusing symbol or function names which some other
macro is using, or creating private system buffers or files which some other macro also uses. Most of the
time when this happens, it isn't that difficult to figure out what is going wrong, but it is a nuisance that you
cannot code something and prove it is correct without considering the rest of the system.
When writing large C or C++ programs, split into multiple source files, you use programming conventions to
avoid such things as name space pollution, e.g. use of statically scoped variables and functions. CRiSP
encourages you to do likewise. Something that is declared static cannot be accidentally affected by some
other macro and gives you a sense of protection. Scoping and global vs. static are discussed in more detail
in the section on "Macros".
Another thing to consider before resorting to a private macro is to understand CRiSP, as a user, and its
philosophy. CRiSP is a complex piece of software when taken as a whole, yet it strives to create an easy to
use user interface for non-technically oriented people. Many people will use certain aspects of the software
and ignore or be totally ignorant of other aspects. What this means is that the functionality you are after may
already be there. If you have work to do and really find something annoying in CRiSP then by all means, go
ahead, and create your own personal macro(s). If you are going to spend a lot of time macro programming
then it is worth examining CRiSP as a whole because you may find useful code libraries or new ideas on
how to achieve things in a faster or more flexible way than any of your original ideas.
There are three things that are worth bearing in mind before embarking on writing your first macro:
1. Learn to use CRiSP properly. Do not be afraid to try things out, as otherwise you may not understand
what the supplied macros are actually doing.
2. Look at the sources to the macros which come with the CRiSP distribution. These not only implement