Crunch CRiSP File Editor 6 - Manual (Page 90)

Page 90
This populates the current keyboard with all the normal typeable characters (A..Z, a..z, 0..9, etc) so
that they are self-inserting (see self_insert).
keyboard_reset
Clears out all key bindings from the current keyboard.
Keyboard binding files
CRiSP provides a facility for storing keyboard bindings in a file separate from a macro. The CRiSP
distribution comes with variety of editor emulations, which are stored in these files. (See etc/*.kbd in the
distribution).
These files are designed to allow you to select a base emulation, and then allow you to modify or enhance
these basic definitions. This facility is provided by a set of macros.
The primitives to enforce this are: set_kbd_name, inq_kbd_name and load_keyboard_file.
At any one time, CRiSP remembers the current editor emulation, e.g. Vi, Emacs, EDT. This allows CRiSP to
load the appropriate keyboard file on startup, and makes it easier for the user to select the bindings from the
setup menu. This current keyboard emulation name is set via the set_kbd_name primitive and can be
retrieved with the inq_kbd_name function.
The load_keyboard_file function allows you to define a set of keystrokes en masse CRiSP without having
to code a set of assign_to_key macro calls.
CRUNCH: Things to watch out for
1. Crunch does not generate code for old style C declarations. The new style must be used.
2. Crunch does not verify that the return value from a function agrees with the return type declared for
the function. (It does check return(expr); and return; statements against whether the function is void
or not).
3. Crunch does no compile-time checking of the reasonableness of expressions, regarding types, For
example:
list l1, l2;
l1 = l1 * l2;
4. Crunch complains about unused arguments sometimes because it cannot intuit whether an
argument is going to be used via the dynamic scoping rules. A language extension or lint-style
comments are needed to tell the compiler not to complain about this.
5. If a local variable is declared at the top level of a function definition with the same name as a
parameter to the function, the user is not warned and possibly incorrect results will occur.
6. Case statements which flow into each other are not interpreted the same as C.
7. When writing replacement macros to overload the functionality of built-in macros there can be a
name scoping problem. For example if you define a macro called printf() and use a parameter fred
as a local variable inside that function then CRiSP may access the wrong variable if fred is defined
in the function which calls printf().
The cm compiler
CRiSP includes a utility called cm which is a low-level compiler and disassembler for CRiSP. The .m
language may be considered as the assembly language of CRiSP, and looks and feels like the Lisp
language. CRiSP internally executes a Lisp-like execution engine and the .m language maps directly onto
this language. The normal C-like crunch language is compiled, using the crunch language, into a compiled
version of the .m code. This results in faster execution.
The major drawback of the .m language, and hence the reason it is no longer in use, is that it is very difficult
to read and write by a human being, because of the plethora of brackets used to enclose execution
statements.
The crunch compiler can be used to generate .m code by use of the command line -c switch. (Normally .cr