Crunch CRiSP File Editor 6 - Manual (Page 87)

Page 87
mechanism. SignalsSIGUSR1SIGUSR2register_macroREG_SIGNALasync.cr
Signal based communication
The SIGUSR1 and SIGUSR2 IPC mechanism is probably the simplest to use and most primitive way to
cause CRiSP to perform an action on demand.
In order to make use of this signal, you need to write a macro which will be invoked when either of these
signals is invoked. (CRiSP treats both signals as identical - you cannot distinguish them from within a
macro).
To register a macro, use the register_macro() primitive using the REG_SIGNAL trigger condition.
CRiSP contains an example macro which utilizes this feature. Consult the file src/crunch/async.cr in your
distribution tree. This macro causes a callback to be invoked when a signal is received. On receipt of the
signal, CRiSP looks to see if a file
$HOME/cr.async exists. If it does, the macro read each line from the
file and executes the appropriate macro.
For example, by placing the following command in the file:
edit_menu_file "filename.ext"
then CRiSP will edit the specified file. You have complete access to all of CRiSPs macros from within this
file. This is a very simple yet very powerful mechanism to cause CRiSP to load a file and display a particular
line number.
When CRiSP has finished with the file, it is deleted.
The example macro has definitions in there to also allow you to poll for the existence of the file, rather than
relying on receipt of a signal. Using the signals can be a problem in that you need to know CRiSPs process
id (PID) before you can send the signal.
The polling timer needs to be configured to a reasonable value (e.g. 1000 milliseconds) before you can use
the macro.
There are obvious race conditions in attempting to use signals or polling timers in this manner, but in
practise since most people tend to use this facility to automatically open files on demand, and since this
occurs fairly infrequently, the race condition can be ignored.
For more sophisticated IPC mechanisms you will need to use any of the other IPC mechanisms.
{button See Also, ALink(ipc,,,)}
Keyboard objects
A keyboard is an internal data structure maintained by CRiSP and is used to keep track of the current
keyboard bindings. Multiple keyboards can be created and different ones assigned to different buffers, e.g.
you could have a set of EDT key bindings in one buffer, vi bindings in another, and compiler specific
bindings in yet another.
All keyboards are the same, but you can stack them up in order to overlay or override default bindings for a
particular buffer.
A keyboard can be set as the default keyboard, so that the key assignments in the keyboard are applicable
to all buffers. Additionally, you can associate a keyboard with a buffer.
The following topics are described in this section
→
Local and Global keyboard
→
Keys and keystrokes
→
Character based terminals
→
Scan codes
→
Creating keyboards and keyboard stacks
→
Keyboard binding files
Local and Global Keyboards
In order to understand what and why keyboards exist, consider what happens when you press a key on the