Crunch CRiSP File Editor 6 - Manual (Page 33)

Page 33
switch is at the end of the command
Debug buffering
Output written to the crisp.log file is normally performed using buffered I/O. Sometimes it may be necessary
to cause CRiSP to flush the output buffer as soon as any data is written to the file. This is most normally
needed when CRiSP is core dumping and the last buffer has not made it to the disk file.
You can cause output flushing to occur by specifying a -1 parameter to the debug primitive. When the -d
switch is used on the command line, you can enable flushing by using the '-f' switch. E.g: "crisp -df" will
start the Motif version of CRiSP and enable debugging, with buffer flushing enabled.
NOTE: Enabling flushing will significantly slow down the execution of CRiSP.
The vars() macro
The vars() macro is a utility function which you can execute at the Command: prompt to display the current
values of all global variables. This can be useful if your macro is using global variables, but is not so useful if
you want to see local variables. The vars() macro is designed to be run after a macro has been finished,
which is why it can only display the state of global variables.
Note: the vars() macro will not show the value of static variables.
Buffers, Files and Windows
In order to understand CRiSP better, it is important to understand the basic concepts of buffers, files and
windows as they are used within CRiSP.
A buffer is a way of manipulating files. A buffer is created when a file is edited. It stores the entire contents of
a file, and keeps track of the changes being done to the file. The user can make arbitrary changes to the
buffer without actually destroying or modifying the original file. Buffers have an undo-list associated with
them. The undo-list allows the user to undo any editing operation applied to the buffer. CRiSP can keep
track of an unlimited number buffers at any time. Each buffer has a set of attributes(pg. 34). which is used to
keep track of the status of the buffer. These attributes may be manipulated by the macro language.
A file has the obvious meaning associated with the underlying filing system. Files can be read into buffers
and manipulated, and not until the buffer is written away is the file on disk actually modified. This allows the
user to maintain a long editing session and only when the user is satisfied with the changes is the file
updated. Also, if the system crashes during an editing session, the original file will not be damaged. CRiSP
contains facilities for keeping backup copies of files, so that even after an editing session the user can go
back to previous versions of the file.
A window is a way of seeing a part of a buffer on the screen. On startup, only one window is visible,
occupying the whole of the screen. This initial window can be split (known as tiling because the windows
always cover the whole of the screen and abut each other). Windows can be split and new windows created.
The only limitation is the size of the screen. If you have too many windows on display, they will be too small
to display any meaningful part of a buffer.
Each window is independent of the others, and the user can select a window and pan around a buffer.
Different windows can display different parts of the same buffer; for example, the user may be looking at the
declarations at the top of a C program, and modifying a piece of code in another window.
CRiSP also supports popup windows. Popup windows are typically used to display information on a
temporary basis, e.g. a list of buffers currently being edited, or a help menu. Popup windows obscure the
background windows normally used for editing. Popup windows are normally created by special purpose
macros. CRiSP contains many macros which use popups to display data.
CRiSP stores all buffers and files in memory; therefore, CRiSP is limited to editing files which are no larger
tan the amount of swap space free. In practise this limitation is very rarely a problem. Most virtual memory
systems support more swap than most of the standard editors can actually use. For example, vi is limited by
the number of lines in the file rather than amount of memory available, and Emacs is limited to a maximum
of 16MB for all editing. CRiSP can cope with very large files on most systems.
There is no limit to the number of files, buffers or windows which can be created at any one time (except for
swap space). Also, files have no line length limitation. This makes CRiSP useful for editing certain types of