Frequently Asked Questions

Please select your question category

Search FAQs
View all frequently asked questions

You will download the version of CRiSP that matches your Linux's glibc version. In order to find out which Glibc version you have, please do the following:

Open an xterm window

Run the following command:


rpm -qa | grep glibc

In order to find out which glibc version you are using on your Linux platform, please do the following:

Open an xterm window

Run the following command:

rpm -qa | grep glibc

Now download the correct Linux binary for CRiSP


The CRiSP workstation license is licensed to be used on a specific workstation for a single user.




The CRiSP networked license is licensed to run on any machine over the network. Users can mix and match different operating systems and hardware platforms. A license manager tracks concurrent usage in a networked environment.


CRiSP commercial use license is for use by businesses, commercial establishments. Commercial license holders can call for technical support during business hours as well as receive support via email at commercial email domains.


Academic use license is for users utilizing CRiSP for academic purposes.


We understand that our users need to use the same editor at home to what they use at work. In order to facilitate that, anytime a user purchases a commercial license for their workplace and purchases yearly maintenance on it, we provide the user a free license for their home use on their choice of platform. The CRiSP home use copy is covered under the same annual maintenance agreement as the purchased license, which includes free upgrades.


The maintenance agreement entitles the customer to many benefits including unlimited upgrades, technical support for the duration of the agreement. Users also geta free version of CRiSP on their choice of platform for equal or lesser value.


The maintenance service dates are typically for 12 months and the dates will be stated on the invoice for future reference.

Maintenance includes the following:

  1. Free minor, major revisions, and enhancements to CRiSP
  2. Free upgrades to CRiSP in case of O.S upgrades and revisions.
  3. New binaries of CRiSP in case you switch any operating system or platform of equal or lesser purchased CRiSP value.
  4. Free additional home use copy of CRiSP for any platform of equal or lesser-purchased CRiSP value.

Please send an email to support@crisp.com for CRiSP technical support.

CRiSP Binaries can be downloaded from crisp.com or vital.com website. If you are having trouble downloading files, please send an email to support@crisp.com




There is no technical difference between a commercial and academic license.




Free technical support via phone and email is offered for the first 30 days of initial purchase. After 30 days of initial purchase, we only offer free technical support via email.

The crunch language is the language used to write macros for CRiSP. The crunch language looks and feels a lot like the C language, and this should help users who are writing macros for the first time, but there are significant differences, which the user should be aware of.

The CRiSP language supports a number of primitive data types:

64-bit integers (int)

64-bit floating point numbers (float/double)

strings (string)

lists (list) - variable length data structure

arrays (array) - variable length data structure, with fast access

structs

CRiSP acts as an interpreter for the language. The programs which the user writes are first compiled to a compact pseudo code format. Although CRiSP is designed to run as fast as possible and use as little CPU resources as possible, the design of the interpreted language is aimed at keeping the size of the macros as small as possible. Writing macros in the crunch language allows the internal architecture of CRiSP to be extended and improved upon in the future whilst maintaining compatibility, at the source code level for user written extensions to the editor.

The other advantages of writing macros in the crunch language is that the macros are totally machine independent, working equally well on Windows or Unix platforms. Macros are also convenient when you do not have access to a C compiler or other architecture specific development tools.

The crunch compiler is implemented using a full yacc grammar of the ANSI C language, and although many constructs may be accepted by the compiler, they may not generate any code, wrong code, or cause the compiler to crash. When in doubt about the correct parsing of a macro, you should run the crunch command with the -c flag. This will compile the source code into the .m intermediate language file (the .m lisp-like language is CRiSP's assembly level code).

In order to write your own macros, you will need to understand various levels of detail. Writing simple one-off macros is easy, but there are a lot of details to learn if coding up complex multi-file macro packages.

1. The syntax of the language. The syntax is very close to ANSI C. For those of you who know this language, this means there is very little mental energy involved in understanding what to write or what to expect.

2. The semantics of the language. This covers the actual context dependent meanings of constructs within the language. This ranges from the meaning of a switch statement, to an understanding of the different data and variable types.

3. The internal data types and objects within the CRiSP language. CRiSP supports objects ranging from 64-bit integer values, to entire buffers containing edited files, callbacks, dialog boxes.

4. An understanding of the macro primitives CRiSP provides. CRiSP provides numerous functions which operate on internal data structures.

CRiSP provides "100%" BRIEF compatibility at the macro language level. This means there is little or no learning curve when writing macros for CRiSP if you have come from a BRIEF environment.

In order to understand how to integrate existing macros, you need to examine what constitutes the BRIEF and the CRiSP macro programming environment.

BRIEF and CRiSP can be examined as three distinct parts:

(i) The low level programming language (.cb files for BRIEF, .cr files for CRiSP).

(ii) The supplied macro sources which constitute the functionality of the user interface

(iii) The actual binary executable (b.exe, mcr, etc)

The CRiSP binary image supports all the low level programming aspects of section (i) above. Thus a macro, such as:

void

fred()

{ int i, j;

for (i = 0; i < 100; i++)

j += i;

message("Sum of 1..100=%d", j);

}

will work identically under BRIEF and all the platforms supported by CRiSP.

The BRIEF/CRiSP macro language is relatively low-level, in the sense that the C language without the standard C library is low level.

BRIEF and CRiSP provide a wealth of sources and compiled macros which provide higher level functions. For example, consider popping up a character mode list selection dialog box (e.g. the Alt-H help menu, or the Alt-B buffer list).

BRIEF and CRiSP provide subroutines to handle this common action of popping up a dialog box, making a selection, and dismissing the dialog box.

However, the difference is that the functions provided by BRIEF and CRiSP are different. In general, CRiSP provides a superset of functionality compared to BRIEFs macros, and CRiSPs macros are essentially written in a 'clean-room' environment to avoid look&feel type issues and other legalities.

Early versions of CRiSP had no macro library of its own, but instead ran totally with the BRIEF macros. At an early point (about CRiSP v1.5), the BRIEF macros were re-implemented, maintaining the same user interface, but using a different implementation style with added benefits:

a) smaller and faster code using CRiSPs better constructs

b) more value added features for the same functionality

It is not feasible to maintain a 100% similar calling convention as BRIEFs for many of these macro subroutines because that would restrict the CRiSP functionality to exactly that of BRIEFs. BRIEF has stood still in terms of functionality more or less for the last 5 years or so. (There were small changes to BRIEFs functionality in v3.0 and v3.1 but nothing radical if you examine the macro programming documentation).

CRiSP has not stagnated but has overtaken BRIEF in terms of programming and user power by a long way. E.g. all the dialog boxes in the GUI versions of CRiSP are all done in the macro language. At one time I was toying with the idea that all existing dialog boxes would be implementable with no changes to the macros, but I found this was just not feasible. Hence today, most of the functionality of the user interface is implemented twice over: once for the character mode interface, and once for the dialog box interface.

What does this mean for you porting your macros?

Well, my experience of talking to people who need/want to do this is that they or the author of CRiSP needs to examine the macros they have and some consultancy-type decisions need to be made to decide what to do.

Some macros port over extremely trivially, especially when they are self-contained and do not rely on BRIEFs macro infrastructure.

Macros which do rely on BRIEFs infrastructure require an examination. In nearly all the customers macros I have looked at, I have found that much if not all of the macro functionality they have implemented is already supported by CRiSP. Remember, CRiSP adds an awful lot of functionality to what BRIEF had. A lot of what customers are doing is needed by many people and so everyone gets the benfit.

The area which is most of a problem is that in which the customer has some complex infrastructure of their own, possibly a large amount of macro sources, which is no longer maintained, because it works.

It is quite feasible and relatively easy to add a BRIEF.H header file to be included by the customers applications which #define's macro interfaces to map between the naming conventions of BRIEF and those of CRiSP. This gets over most of the easy stuff.

Other areas may rely too much on the DOS way or working (e.g. filename conventions), or on the BRIEF dialog manager (CRiSP provides an equivalent and more powerful facility to this). It is not easy to say how much work is involved in this, and the best that can be done is to offer free technical support, within reason, to those customers porting code to CRiSP, or to offer a consultancy service where most if not all of the porting is done for the customer.

Keystroke macros is a facility where you can record a sequence of keystrokes and replay them, For certain repetitive types of editing, this can be a great time saver. Keystroke macros have their limitations - when things get too complex for a keystroke macro then it may be time to write a custom macro.

CRiSP allows you to record keystroke macros and to save them across sessions - possibly giving them memorable names and managing them.

Basic Keystroke Macro operation

The simplest way to start using keystroke macros is record a macro and then immediately play it back.

To record a macro, press the function key. A message will be displayed indicating that a macro is being recorded. From now on, all keystrokes are stored away as part of the macro. When you have finished recording the macro, press again. (You can use the EditMacro start/stop and Macro playback entries as alternatives to the function keys).

If you have already recorded a keystroke macro, then you will be prompted before overwriting the existing macro; this gives you a chance to avoid destroying the prior macro before proceeding on to the next one.

When recording a macro only keystrokes are recorded - not mouse selections or access to the menu and toolbars. You can get confusing results when a macro is played back if you have done so.

To play back the last recorded macro, press the key.

You can undo the action of a playback using the Undo function.

Keystroke Macro management

The / functions for macro recording and playback are suitable for short-term macros. If you want to build up a repertoire of macros, it is necessary to save the macros and give them memorable names.

Searching and Macros

When executing a keystroke macro, sometimes it is useful to do a search and then perform an action, for example, find next occurrence of a word, and then edit the line below. Keystroke macros are not very programmable but you can set the search_abort option so that if a search fails, then the remainder of the keystroke macro is aborted. You can set this using the command prompt:

set search_abort

command. You can disable this with:

set nosearch_abort

Please fill out the following form and email it to  support@vital.com

Company Name :
Contact Name :
Phone Number :
Fax Number   :
Email Address :
Postal Address:


Did you purchase maintenance:
Maintenance Contact:

Primary Editor :

Where did you hear about CRiSP :

Purchased From :
Price Paid :
Method Of Payment:

Number Of Licenses Purchased :

License Type: Workstation / Network:

Hardware:

Operating System :

CRISP Version [Help->About CRiSP]:

UNIX / Linux / Apple platform
Network License: Output Of Following Commands On The Machine Where License Manager Will Run
/usr/local/crisp/bin./lmcrisp -hostinfo:
hostname :
hostid or uname -i:
uname -sn :

Workstation License
/usr/local/crisp/bin./lmcrisp -hostinfo:
hostname :
hostid or uname -i:
uname -sn :


Windows 2000 / XP / Vista
Start->Run-cmd
cd c:program filescrispbin.w32
lmcrisp -hostinfo

OR

Start CRiSP up [It will come up in demo mode]
Help->About CRiSP
Value of the field HOSTNAME:
Version Number Of CRiSP:


Please email the completed form to:
VITAL
Ph: +1 (972) 378-3843
Fax: +1 (972) 473-6272
Email:  support@vital.com

CRiSP Version Simulation

CRiSP license manager provides a mechanism to allow you to use an older release as if it were a newer one. This is typically done, say after a license upgrade. You might have 50 licenses for the v8 product, and then need to upgrade to v9. But then some users may want to continue using v8 users.

Rather than issuing an additional set of v8 licenses, you can ask CRiSP v8 to pretend it is operating as the v9 product and use a valid version 9 license. This avoids the need to running separate license managers for v8 & v9. This is done by setting the environment variable CR_LICENSED_VERSION in the users profile.

e.x.:

setenv CR_LICENSED_VERSION 9.0

You will need a valid version 9 license in order for the above to work.

These instructions are applicabe for troubleshooting node-locked, workstation, fixed license(s) on UNIX and Windows platforms.


Node Locked License Testing Instructions:


1. Go to the following directory where CRiSP is located.


cd /crisp/bin. -- UNIX

cd crispbin.w32 -- Windows

2. Please delete the file license2.dat in this directory


3. Make sure you have installed the license.dat file that you received from Vital.


Use the following command to display the license.dat file.


more license.dat


cat license.dat


The license.dat should not be blank or with the serial FOXTROT BETA. If the license states FOXTROT BETA, then you have not installed the correct license.dat file.


4. Execute the following command on the UNIX shell prompt or Windows MS-DOS Prompt.


/crisp/bin./lmcrisp -v


This command simply checks out the license.dat file for diagnostics purposes. The output should state license file checked out OK. If not, then pipe the output to a file as follows:


lmcrisp -v >v.txt


5. Execute the following command twice on the UNIX shell prompt or on the MS-DOS Prompt.


/crisp/bin./lmcrisp -init

/crisp/bin./lmcrisp -init


This command initializes the node-locked license database. This test displays information about the license.dat file and will display clues and reasons for license failure. The output should state Product CRISP.... initialized and have no product errors. If there are errors, then pipe the output to a file.


Use the following command to pipe the display to a file.


lmcrisp -init >init.txt


6. Execute the following command with a command prompt or MS-DOS Prompt.


/crisp/bin./lmcrisp -licinfo


This command displays the license status summary. This test may provide hints for license failure. Use the following command to pipe the display of the above command to a file.


lmcrisp -init >licinfo.txt


7. If there were no errors displayed, then run CRiSP.


If at startup you still get the license expired message, please email the output of the following commands to support@crisp.com


To find the host information, go to the bin. directory and execute the following command:


/crisp/bin./lmcrisp -hostinfo

Use the following command to pipe the display to a file.

lmcrisp -hostinfo >hostinfo.txt

Please email the files license.dat, v.txt, licinfo.txt and hostinfo.txt to support@crisp.com


Once you are under yearly maintenance contract, you get free upgrades for a year. You will need to stay current with the maintenance contract to receive the upgrades free of charge.







The maintenance is a value added feature and in most cases the annual contract cost less than a one time upgrade cost.

Microsoft Windows Networked License Manager:

Customers have the ability to purchase a networked license manager on a Windows platform. These notes are designed to guide you in installing and configuringthe networked license manager.

It is normally expected that the Networked license manager facility would be installed on a Windows NT / 2000 / Vista server.

The license manager is called LMCRiSP, and the binary for this is in the lmcrisp.exe file in the BIN.W32 installation directory for CRiSP.

Installation under Windows NT / 2000 / Vista

Windows NT / 2000 / Vista� has the concept of a 'service'. A service is a special program which normally runs before any user has logged into the system and which is protected from being killed when a user logs off.

In order to install a service, you need to have Administrator privileges. If you do not want to install the license manager as a service, or if you do not have access to the Administrator account, then you can just run the software manually as in the case for Windows/95 in a window of its own.

A service has to be installed and when installed, can be controlled from the CONTROL PANEL / SERVICES applet.

If you have never looked at the SERVICES applet, now is a good time. Invoking this brings up a dialog box showing a list of services on your machine, some of which are hardware related and some software related. Some services are started automatically for you when the system boots and others can be manually started.

Before the CRiSP license manager can be used by the SERVICES applet, you will need to install it.

To do this, you need to run the lmcrisp.exe binary with a command line argument:

lmcrisp.exe install

NOTE VERY IMPORTANT!!

Windows/NT 4.0 appears to have a problem with a service which is stored in a directory whose path includes one or more spaces.

The default CRiSP installation normally involves installing in a directory where spaces are used in one or more components of the directory name, e.g. C:Program FilesCRiSP .

If you attempt install lmcrisp.exe from its default location you will not be able to start it from the service manager. Not only that, it is difficult to find out which program will be invoked when the service is started.

This can lead to a very confusing situation where the service refuses to start yet it is unclear why. If you subsequently move the lmcrisp.exe to some other directory you can have great difficult uninstalling the service.

To get around this problem, it is suggested that you copy lmcrisp.exe to somewhere where spaces in filenames will not cause a problem, e.g. WINNT, i.e. the home directory of your NT installation.

Having found a suitable location to launch the license manager, run the following command:

C:WINNTLMCRISP.EXE install

(The 'install' should be in lower case). This will now make the license server visible in the control panel's SERVICES applet. If you already had the services applet open, those close it and restart it to refresh the contents.

You should now see an entry for the CRiSP license manager:

CRiSP License Manager - Manual

You can now start up the license manager by selecting the Startup button. The license manager is now available for use. You may find it worthwhile to have the service automatically started when the system boots.

License and Log files

If you copy the lmcrisp.exe executable to an alternate directory, then you MUST put a copy of your LICENSE.DAT file in that same directory. lmcrisp.exe expects to find this file in the same directory as the binary.

As lmcrisp.exe is running it will create a log file of any activity, such as license requests. This is stored in the file lmcrisp.log in the same directory as the lmcrisp.exe service is started from.

De-installing and upgrading the license manager

This section only applies to Windows NT users if the license manager has been installed as a service.

If the license manager has been installed as a service and is currently running, then you will not be able to delete or rename the executable lmcrisp.exe. To do either of these operations you will need to stop the service, using the control panel's services applet.

Once the service has stopped running, you will be able remove the lmcrisp.exe file or upgrade the software as appropriate.

If you want to totally decommission the license manager, then you will need to run the lmcrisp.exe binary with the 'remove' command line option:

C:WINNTlmcrisp.exe remove

This will stop the service and remove it from the services applet dialog. (You may need to stop and restart the services applet to refresh its contents to be sure the service has been removed).

Changing the license.dat file

If you need to make any changes to the license.dat file then you will need to stop and restart the license manager so it can re-read the configuration file.

Remember, that if you have installed the license manager outside of the CRiSP installation directory that it is the LICENSE.DAT file in the same directory as the LMCRISP.EXE that needs to be updated. You are advised to ensure that a copy of the license.dat file should also be located in the BIN.W32 directory where CRiSP is installed so that CRiSP knows what to do.

Running CRiSP

If you are using the floating license facility, then you will need to set the environment variable:

set LMCRISP_HOST=

of the host which is running the license manager. If the license manager is running on the current machine, you could use:

set LMCRISP_HOST=localhost

(Previous versions of the license manager used the environment variable DDMF_HOST; this can still be used, but LMCRISP_HOST is the preferred name to use).

Please find attached your license file. The file needs to be renamed to license.dat if it is not already so.


Workstation License:

UNIX & LINUX & APPLE
Please save the file in the following directory where you have installed CRiSP binaries

By Default the directory is: /usr/local/crisp/bin.platform
Make sure that the license file is named license.dat and not license.dat.txt or anything else.

WINDOWS:
Please save the file in the following directory where you have installed CRiSP
By Default the directory is: "C:⁄Program Files⁄crisp⁄bin.w32"

Make sure that the license file is named license.dat and not license.dat.txt or anything else.

Networked License:
Step 1:
Please save the attached file in the following directory where you have installed CRiSP binaries. Make sure that the license file is named license.dat and not license.dat.txt or anything else.

By default the directory is:

UNIX: /usr/local/crisp/bin.platform
Windows: C:/Program Files/crisp/bin.w32

Step 2:

Open up an xterm or a Command Window.

Change Directory where CRiSP binaries are installed and you have placed the license.dat file.

Start the license manager process:

UNIX: ./lmcrisp
Windows: Start the process lmcrisp as a service

Step 3:
For all Client Machines, please set the following environment variable in your .profile or .cshrc. Please contact your systems administrator for assistance with this.
UNIX:
Cshell: setenv LMCRISP_HOST

ex: if license server hostname is "fred", please set the env variable as follows:
setenv LMCRISP_HOST fred

Korn Shell: export LMCRISP_HOST=

ex: if license server hostname is "fred", please set the env variable as follows:
export LMCRISP_HOST=fred

WINDOWS:
SET LMCRISP_HOST License-Server-Machine-Name

ex: if license server hostname is "fred", please set the env variable as follows:
SET LMCRISP_HOST fred




CRiSP is 100% compliant with BRIEF. Where it is not compliant is that crisp has added lots of functionality which BRIEF never had in the first place, and the macro library which ships may not provide the same functions as you had with BRIEF. E.g. the way character mode popup windows works is different.

If you have your own macros - how easy/difficult it is to integrate them is simply limited to deciding how to invoke them. E.g. you can change the startup.cr macro to call your macros or use the setup menus to define a startup macro. In BRIEF - there was no setup, it was done by the SETUP.EXE utility. In CRiSP everything is set up from inside the editor - although the character mode version only provides a subset of all settable things compared to the crisp.exe gui version.

The first thing is to compile your macros using "crunch.exe" (instead of "cb.exe") and see what compilation issues there are. They should compile fine, unless you are relying on the BRIEF header files. You should

# include

for CRiSP, and you shouldnt be too far away.


Autosaving
is used for automatically saving files you are editing on, e.g. if you
walk away from your terminal and forget to save, or for automatically
saving modified files after a number of keystrokes.

CRiSP provides an autosave and autowrite option. When an autosave is performed, CRiSP will write a temporary copy of any modified buffers to a temporary file (usually located in the backup directory). Autowrite means that the file will be automatically saved for you, as if you had performed a command, i.e. the original file on disk will be saved.

Autosaves are useful if you are working in an environment where it is likely for your computer to fail, or for the network you are connected to has problems. Autosaves avoid you having to save copies of files using the normal File-Save mechanism, yet still allow temporary copies of the files you are working on to be saved.

Auditing
This option can be used to create an audit trail of file activity. Whenever you save a file, CRiSP remembers the names of the files you have edited. When you exit, this list of files is written to an audit trail. This allows you to perform a days worth of editing and know exactly which files you have saved and at which times, e.g. so you can update source code control comment archives.

By default, the archive file is stored in your configuration directory under the file Archive.log.

You can also turn on and off this option via the set [no]audit command prompt command.

Autosave time
This field allows you to specify how frequently the autosave mechanism kicks in. The autosave mechanism is used to cause modified buffers to be saved to disk without destroying the original file, e.g. in case of a system crash. The autosave mechanism can be configured to kick in after a period of keyboard inactivity or after a set number of keystrokes.

If the idle time is a positive number greater than zero then this is the idle time (in seconds) before the autosave mechanism kicks in after the last key is pressed. If the idle time is zero then the autosave mechanism will be disabled.

Autosave (key-count)
This specifies that autosaving of files will be triggered after the user has typed in a certain number of keys. This is useful when you will be typing in a lot of text, and the normal autosave timer would not be relevant, since CRiSP would not be idle for long enough for the autosave to come into action.

Autowrite
If this option is enabled, then instead of writing to a temporary file, the modified buffers will be saved directly to disk as if a File Save command had been done.

If this option is enabled, and you are editing a remote FTP file, then you can set an option for remote files to have them automatically uploaded when the autosave is invoked.
Filename prefix and Filename suffix

These options let you override the default characters appended and suffixed to the filename when creating autosave files. The default characters (@) are designed to make the autosave files stand out in a directory. If specifying the suffix, then you may need to put a dot at the front to give the files a visible extension (e.g. .asv).

Save on loss of focus
If this option is enabled, then all modified buffers will be saved when the cursor moves out of the window (i.e. another application gains input focus). This is useful if you keep switching between applications, e.g. a development tool and the editor. It avoids having to manually save the files.

There can be a short delay between leaving CRiSP and entering the other application before the file save is completed. Under Unix, CRiSP checks every 2 seconds to see which application has the input focus. Under Windows, detection of loss of focus is more instantaneous. But when saving lots of modified files or large files, there can be a delay before the file is ready for the other application to manipulate.

You can change the default Unix poll time by setting the environment variable CR_FOCUS_LOSS_TIMEOUT to a number in milli-seconds if you want to make the detection quicker.

Save to file directory
By default files are autosaved to the backup directory. If no backup directory is defined then the autosave files are stored in the directory where the file exists.

Setting this option allows you to save autosave files to the directory of the file irrespective of the backup directory setting.

When the autosave mechanism comes into play, each modified buffer will be saved to disk with a filename based on the original filename. (Under Unix systems autosave files add a '@' character to the start and end of the original filename, for example, the file fred.c becomes @fred.c@, thus causing all autosave files to be bunched together in directory listings; under Windows the file is named by the original filename but with an .ASV file extension). These autosaved files are exact copies of the current buffer contents and the files are deleted when exiting CRiSP, or if the buffer is closed. Only if CRiSP core dumps, the system crashes, or you accidentally kill CRiSP will these files be left lying around.

If a backup directory has been defined, then autosaved files will be stored in the backup directory, avoiding clutter in the user’s directories.

Infotips, or code completion, is a facility for

providing context sensitive help in the form of a popup menu or tooltip

whilst you are typing in code. It is ideal for working on code where

you have lots of functions or data structures but cannot remember

exactly the syntax or format of a specific item. For example, the TCL

language provides a number of functions which perform a generic action,

but the specific task they perform is controlled by the first argument

passed to the function.


For example, the [string] function takes a number of arguments to perform things like string matching, sub-string extraction etc. By typing in the function as in:

[string

with the cursor placed after the string keyword, a popup will appear:

Types of Tips
When tips are enabled, then the tips will popup automatically as you are typing - you don’t need to remember any keyboard shortcuts. There are two types of tips - menu tips where a list of possible options are shown, and unambiguous function help tips, showing the prototype of the function or entity you are typing. Function tips are normally popped up as a result of typing open parenthesis or a comma

When typing a function call, CRiSP will popup a reminder tip as you type each function argument, highlighting the argument you are typing.
Menu tips are shown when there are more than one valid definition of the object (function or structure/class member). You can scroll through each one, and a popup function tip will show to the side of the menu popup (if one is available).
CRiSP will normally scan your own private tag database as part of your project to show you valid definitions. If no definitions are found then CRiSP will rely on its own built in database of tips. CRiSP comes with a variety of databases covering C, C++, Java, Perl, TCL, Cold Fusion, and SQL.

Enabling Tips
Infotips can be enabled on a per file extension basis. Visit OptionsLanguage Editing Modes where you can enable the tip for persistent settings.
The set tip command can be used to temporarily change code completion for the current buffer - either to enable or disable it. You can enable tips for the current buffer using the following Command: prompt set command:

set tip

You can disable tips by using the command:

set notip

Invoking Tips
Normally, an infotip will popup as you are typing in. CRiSP detects the type of construct you are typing and based on internal databases or project tag files, will display a list of valid options. You can force CRiSP to evaluate the current construct and show a list of options by using the key. You can use this even if tips are turned off, or if you have just dismissed the popup window.
Examples of Tips
CRiSP supports a number of languages for info-tipping. Different languages have different specifications and the features provided by CRiSP vary for these languages. The following examples illustrate simple examples of invoking the tip feature.

HTML
CRiSP provides support for HTML files, prompting you with the valid element names after an opening angle bracket. To see this in action, edit a new HTML file, and type <. If tips are enabled then a popup menu will show the valid HTML elements available. To the right of this menu will be a comments window, showing a description of the element and the available attributes. (If tipping is not enabled, then press to get the popup).
You can scroll through the list of valid elements and click on the attribute links for each element to get a short description of the features available.


This dialog box is part of the Language editing

modes dialog. These options allow you to specify various options which

are helpful to programmers or people who have to deal with files with a

fixed format (source code, shell scripts, special syntax data files).

The template editing facility relies on macros to provide support for various languages. An alternative to this mechanism is the abbreviations facility. Abbreviations are file-type specific dictionaries of words and their expansions. Abbreviations do not offer the sophistication of the language template modes, but may be of use for languages you need if CRiSP does not support a template for your language.

Bracket Style

When template editing is enabled (via Template language), CRiSP may need to know what your personal style is for indenting and handling bracket statements. For example, in C & C++, the curly brace characters are used to delimit groups of statements. In the VERILOG language, the keywords BEGIN and END are used. When CRiSP fills in a template construct it needs to know how to position these brackets or keywords. There are a number of different styles in use, and so all styles are provided. The example below illustrates the styles using C coding.

K&R CRiSP Unindented Indented GNU

===== ===== ========== ========= ===

if (..) { if (..) { if (..) if (...) if (...)

... ... { { {

} } ... ... ...

} } }

Colorizer

The colorizer facility may be used to automatically highlight comments, strings, numbers and/or keywords in a source file. CRiSP provides support for various languages, including: ADA, BASIC, COBOL, Fortran, C/C++, and Verilog HDL. You simply select the file type associated with this file extension, and CRiSP will do the rest.

If you want to build your own customized colorizer definitions, then you will need to consult the CRiSP Programmer’s Guide

Template language This option allows you to use the template editing mode. It enables you to type in partial language constructs and have CRiSP automatically recognise what you are typing and complete the construct for you. CRiSP provides support for a number of languages, including ADA, C and Verilog.

Template editing will be invoked automatically by pressing a or after typing in part of the construct. (The actual character will depend on the options set)..

Minimum abbrev

This field is useful when using the key to perform template expansions. You can set this field to a value which specifies the minimum number of typed characters on the line before the template expansion is performed.

It is designed to avoid accidental expansions when using the key.

Note that you can always undo an automatic template expansion by using the undo command ( or the undo icon, for instance).

Template options

These options allow you to tailor how the expansion mechanism will be used. At present there are just three options, but future versions of CRiSP may add more options for different languages.

Expand inside comments. If enabled, CRiSP will perform template expansions, even if the cursor is inside a comment. Disable this if you do not want this to happen, e.g. if you having expand on space enabled, then this may be inconvenient if typing normal text.

Expand on . If enabled, then CRiSP will look at the word or partial word you have typed on the line and see if there is a suitable template expansion. Since is such a common key to type, it may be preferable to use the option instead.

Expand on . Same as the expand on option above, but tries the template expansion when the key is pressed.

Expand on . This option controls whether automatic indenting or unindenting should occur depending on the keyword on the line. Whether this option has an affect will be dependent on the template language selected. E.g. non-block structured languages are likely to ignore this option totally.

Note: As of CRiSP v5.0.0m this field is unlikely to perform any useful function if enabled. However, future versions may add language specific support for this option.

Expand on {. This is designed for languages such as C or C++ which use the curly brace to enclose blocks of statements. If this option is enabled and the selected language template supports it, then a pair of braces will be inserted with the appropriate indentation you selected.

In any of these modes, you can avoid template expansion by using the key to quote the next character you type.

Enable } placement. If this option is set then CRiSP will intercept the } key being pressed and place the bracket in the appropriate part of the line to match the current blocks indentation structure.

Enable popups Some templates will put up a dialog to prompt for values to be inserted. If you disable this then they will be inserted with no popup action.

If you are having a problem with CRiSP and you have been asked to send a crisp.log file, then follow the steps below.


Location of the log file

================

Under Unix the log file is written to /tmp/crisp.log. If that directory is not accessable or a crisp.log is located there but owned by someone else, then CRiSP will use the current directory.


Under Windows, CRiSP will attempt to write to tmpcrisp.log. If you do not have a tmp directory then the file will be written to the current directory.


The crisp.log file is a trace of the macro instructions executed during a session. This can be a lot of output, so don't be alarmed at its size (a complete start/end session can result in > .5MB of text).


There are two ways to create a crisp.log file:


(1) Start CRiSP up, and enable debugging just before the questionable event. To do this execute the 'debug' command at the Command: prompt.


debug


CRiSP will respond with a message like:


*** DEBUG ON (0x0001) ***


Perform the action, and then turn off debug by repeating the debug command:


debug


This minimizes the size of the output file.


(2) If the problem occurs possibly during startup, then trying to access the Command: prompt would be too late. You can use the '-d' command line switch to enable debug on startup:


crisp -d


You can turn off the debug as in (1) above.


If you are running under X-Windows, then you may need to use the '-debug' switch instead of '-d'. These are equivalent.


Segmentation Violations / Automatic Exit

========================================

If the problem you are reporting is a core dump (segmentation violation under Unix) then you will need to turn on flushing.


Under Windows, a segmentation violation may cause CRiSP.EXE to simply disappear without warning.


By default CRiSP writes to the log file in buffered mode, which is fast. Flushing-mode severely slows down CRiSP (by a factor of 10 typically), and is only needed if CRiSP is dying.


In flushing mode, CRiSP will keep on flushing the to the log file; without it, the last few lines of the log file may be truncated or lost which can hamper attempts to figure out what has happened.


Enabling flushing:


(1) From inside CRiSP, execute the debug command with a -1 argument:


debug -1

(2) From the command line, use the '-f' command line switch, e.g.:

crisp -df

Final note

==========

If you are writing your own macros, feel free to use this facility to see what really happens to help you debug your own macros.

CRiSP supports a DDE interface. You can find details on this in the Programmers Guide.Specifically:

1. Enable the 'crisp server' option in the CRiSP Options->Startup

dialog.

2. There is a source and binary which accompanies crisp

(srccdde.c and dde.exe) which can be used to test out the interface, e.g.

dde -s CRISP -t COMMAND [+] filename

will cause crisp to load filename and jump to the line-no if specified.

You need an environment variable something like:

CRiSPDDE=CRISP;COMMAND;edit__file "%s";goto_line %d

Project->New

This dialog is used to create a new project. To create a new project, you need to give it a name. This name is used as part of the filename where the project information is stored. Each project is stored in a file (with a .prj file extension).

You can elect to store the project in a specific directory or store all your projects in the same directory. Storing all your projects in one place makes it easier to select between the projects. Storing a project within the directory tree of that project has the advantage of being able to archive and backup all files for the project, including the project definition file.

Type in the name of the new project in the Project name field, or select an existing project from the list, and click on Ok.

The SUN WorkShop product is a visual development tool for building, and debugging applications on the SUN Solaris platforms.. The development tool provides access to a number of applications, including a compiler, debugger, editor and other build and analysis tools.

Unfortunately, the integrated environment only provides direct support for the vi and emacs editors. The CRiSP integration facility allows CRiSP to be controlled from the interactive development environment (IDE) by pretending to be a copy of Emacs. In order for this to work, it is necessary to modify the installation of the WorkShop package as described below.

Installation

In order for CRiSP to work in conjunction with the IDE, it is necessary to amend a part of the SUN WorkShop installation so that the IDE believes CRiSP is actually a copy of Emacs. Doing this will normally require root access to perform the set up.

Assuming WorkShop is installed in its standard location, you will need to amend the following file:

/opt/SUNWspro/bin/xemacs

This is a symbolic link to the Emacs binary provided with the WorkShop environment. In doing this change, you will affect the ability for other users on the system to use Emacs if you want to use CRiSP.

Firstly, rename the file as follows:

cd /opt/SUNWspro/bin

mv xemacs xemacs.orig

Now create a shell script in its place to invoke CRiSP as follows:

#! /bin/sh

exec crisp -pworkshop

If you want to be able to have some users using Emacs and some using CRiSP on the same system then you could create a script such as this:

#! /bin/sh

if [ -f $HOME/.crisp.workshop ]; then

exec crisp -pworkshop

else

exec xemacs.orig “$@”

fi

CRiSP users simply need to create a place-holder file,$HOME/.crisp.workshop, and the SUN WorkShop will automatically invoke CRiSP when they go to edit a file. Emacs users simply need to ensure the above file has not been created, and everything will be the same as before.

Finally using the WorkShop Options/Text Editor Options dialog, select the xemacs editor option as your preference.

This section is designed to introduce the basic things you need to know to write your own macro. If you require further information, consult the introduction at the top of the Programmers Guide on-line help.

If you have never programmed a macro in CRiSP before then here are some tips to get you started:

The macro language (known as crunch) is an ANSI-C like macro language, e.g. you define functions which are callable (from the Command: prompt, for example), and which can be assigned to keys. The macro language provides numerous data types and internal builtin functions. The most common data types are strings and integers. (crunch does not provide support for pointers, but you will find you do not need these anyhow). Automatic garbage collection is provided for - you can create objects and the memory allocated to them is released when the objects go out of scope of when the owning object is destroyed.

Macro files end in the file extension .cr. To create a macro file, edit a new file with the appropriate extension. For example, create a macro file called mymacro.cr. Insert the following into the buffer:

# include

void

mymacro()

{

message(“This is my macro!”);

}

The #include statement is something you will need sooner or later in the macros you write. Although it is not needed for this simple macro, you may need it as you extend your macro. The crisp.h file contains numerous constant definitions which you need for some of the builtin functions of CRiSP.

This macro file contains a single macro, called mymacro. You can execute this macro after you have compiled and loaded the macro. On most machines, just press the key and the macro file will be compiled and loaded into memory.

On some Unix platforms running the Motif window manager, you may find that zooms the CRiSP editing window to the full screen size. In this case, execute the command load at the Command: prompt. You can access the Command: prompt by pressing the key.

After compilation, you will find a file called mymacro.cm in the same directory as the original source. This is the file which is important to CRiSP. (On the other hand, the file mymacro.cr is important to you).

You can add multiple macros to your macro file and build up complex personal macros to do whatever you want. It is a good idea if you are going to do extensive macro writing to browse the CRiSP supplied macros and investigate whether some function you want to write is not already available directly, or callable as a subroutine.

If you want to have your macro file loaded automatically on startup then enable the OptionsStartupStartup macro menu option. Type in the full path to your .cm or .cr file.

The template editing facility is a convenient way of reducing typing when creating program source files or using file formats. When you use template editing, you can configure the or key so that when you type either of these keys, CRiSP will look at the work you have just typed and attempt to match the word (or partial word) against a list of templates and substitute the word for the matching text.

This has the following benefits:

1. Makes it easier to use an unfamiliar language, where it is hard to remember the exact syntax of a language construct.

2. Enables you to write code or document files which conform to a certain company or personal standard with respect to layout.

Template expansion is file specific - you can configure different file types to expand template differently, e.g. shell scripts and C/C++ programs would not use the same templates. Also for some plain text files, you may not want any form of template expansion. You use the OptionsLanguage Editing Modes dialog box to set up options.

In general, template expansion is controlled by a language template file. CRiSP comes with a collection of these files located in the crisp/src/template directory. These files all end in a .tpl file extension. These are plain text files; they contain commands and directives regarding the special features of the language they describe together with a list of expandable templates. The format of these files is described the template file format section.

You can create your own template files and keep them private from the standard templates, or update the installation files, e.g. to provide a common template for all users. Each user can have their own private set of templates.

You can configure how a template is invoked, e.g. after typing a space or tab character. The template mechanism looks at the text currently on the line. If you have just typed a few characters on the line, with the cursor at the end of the line, then the template list will be searched. If text appears to the right of the cursor, then no template expansion will take place, avoiding problems when editing existing text.

CRiSP supports personalised bracket styles. Many languages are block structured, allowing you to treat a sequence of statements as a single line of code. The language typically use keywords such as BEGIN and END to delimit the blocks of code; the C/C++ language family use the open and close curly brace characters.

Different people and different organisations have standards for the relative placement of these block delimiter keywords, e.g. indented on the next line, or aligned with the statement they form a part of. CRiSP supports a number of different and common bracketing styles. You can configure different styles for different file types.

One of the useful features of the template mechanism is Visual Template. This is a popup dialog box which shows you the templates available for the selected language, allowing you to point and click to insert templates. The same template files are used for the keyboard and visual templates. So you can create long and esoteric template files, without having to remember the assignments that were created. You can use the visual templates to start off with and as you remember the templates you can use the faster keyboard shortcuts.

The call graph facility is mechanism to view a program via the way that functions call each other, allowing you to quickly find which functions or methods call a specific function and in turn which functions are called by a function.

CRiSP provides the Function Calls dialog to allow you to view the relationships between functions and references. This includes the ability to generate a report of all functions which are not actually referenced anywhere, ie are candidates for deleting.

You can access this facility via the Tools{bmp rarrow.bmp}Function calls menu item, or using the command line calls macro. The calls macro can be used (specify the name of the function to show) and the results pop up into a character mode popup window.

Alternatively the more feature rich Function Calls dialog can be accessed to allow interactive function walking.

NOTE:

In order for the call graph mechanism to work requires a tags database which includes cross-referencing information. Without the cross-reference information, CRiSP cannot determine the functions called by another function.

The call graph dialog shows two views – a table view and the more powerful tree view.

If you select a word before invoking the dialog, then CRiSP will automatically show you the list of functions which call into this function and functions called by this function.

To show the results for a function, type in the name at the top of the dialog and click on the Ok button. If you double click on the results entries then you can follow the chain of functions.

Use Edit to edit a specific entry.

Tree View

The tree view provides more power to view the graph. It handles ambiguous tag matches - if you type in the name of a function, for example, and it is defined in more than one place, each place will be listed. You can expand the call tree to show two branches - calls and called functions, and for each branch you can follow the chain.

Note however, that this call graph is based on fuzzy logic parsing and it cannot know the actual semantic correctness of the call tree. For example, if you have a function which calls into another function, e.g. do_something, but there are two or more do_something functions or methods, the parser cannot know which ones are actually called, so both entries will be listed and it is up to you to decide the validity of the results.

For the calls branch of the tree, the list of called entities is reasonably correct, but it may not show entities which are actually called, but for which no definition exists anywhere, e.g. calls into an external library. It will work however if prototypes are available for externally defined entities.

For the called by branch, the results will be necessarily less accurate - for the reasons given above for the do_something function

Unused Entries

This tab is used to generate a report of all functions which are not referenced. This can only work if the tag database is created with the cross-reference information option. For every definition in the database, CRiSP checks the cross-reference table to see if any other function or method refers to the definition. If not then the entry is listed.

The report is reasonably accurate - if something is listed then it cannot be referred to (unless the underlying tag code does not parse the language properly). Conversely, just because a symbol is not listed does not mean it is actually referred to (e.g. it could be #ifdef’ed out - i.e. it does not really exist).

Generating a report can take a fair amount of time.

The tag options dialog is used for configuring the default paths when locating tags, and to specify options controlling the browser window.


Project tags path


Use this to specify per-project tag file names. You can associate different filenames depending on your current project. You can specify multiple filenames (although it is best to have a single tag file). You can use the prefix %dir to indicate that the directory of the current file should be used. For example, %dir/tags would be useful if you store a tags file in every source directory. In this instance CRiSP would search the directory in which the current file is located to find a tag.


You can specify multiple filenames; under Windows, where spaces can be present in directory names, you should enclose each filename in double quotes to avoid ambiguities.


Global tags path


The global tag path is specified in the same way as the projects tag path. The global tag files are searched after checking the project files. The global tag files are best used for project-independent files such as the compiler supplied include files.


Options

Some of the options below are used by the Contents/Browser window. Other options affect the interactive tag finding commands.

Auto create tagfile


If enabled then CRiSP will automatically create a tags database file, even if one does not exist, as you edit files. Normally you would create a tag database manually in the top level directory of a project. Using this function might be useful if you wanted to maintain a separate tags database in each directory. Using a relative file name in the project tags path would allow the name of the tag database to vary so that only the database in the current directory is used.


Include prototypes

Include XREFs


When jumping to a definition with the toolbar icon or the shortcut, if multiple definitions are available then these options control whether to display prototypes or cross-references. Most of the time programmers would want to jump to the definition of a function or method rather than the prototype declaration, and if you include prototypes, then more than likely 2 or more definitions will show in the popup. Disabling them may avoid the popup and jump to the direct definition.


Show ambiguous tags


If enabled then when using the Command: prompt tag command, then all objects matching the named item or which have the named argument as a prefix are shown in a popup window. Without this option set, only objects which exactly match the named item are shown if an ambiguity arises. If this option is disabled, then you can achieve a similar affect by suffixing the object name with an asterisk wild card.


Update in background


If enabled, then CRiSP will automatically refresh the browser window whenever the time limit below is exceeded. This ensures the browser window is consistent with the current file you are modifying.


Update on save


If enabled, then CRiSP will update the browser window as you save the files you are editing.


Update check (seconds)


Specifies how frequently to automatically update the tags files as you are editing.


Max files to scan


Specifies an upper limit on how many files to examine when performing an update. If you set this limit too high and are editing a large number of files, then you may notice a slight pause as CRiSP refreshes the browser window.


Max files to update


Specifies an upper limit on how many modified files to scan when updating the browser window.


Water marks

The water mark options are used to limit the amount of information displayed in the browser window. For larger projects, showing all functions or methods can cause thousands of entries to be displayed, which not only can be difficult to navigate, but can use significant amounts of memory. On slower systems, or systems with limited memory, this can cause significant delays or can be a nuisance if you accidentally click on one of the branches to expand the tree.


The water marks provide a get-out path. As the tree is expanded to show the items, if the number of entries being added exceeds the first water mark, then a dialog is popped up asking whether you want to continue.

Three water marks are defined. The first is a low limit giving you a quick chance to abort the operation. The second one is a higher limit which lets you see more without having problems with very large lists, and the third provides effectively an upper (infinite) barrier. If you have a lot of memory and a fast machine then you can just increase all the limits to a reasonably large number (like 100,000 or 1 million), and you would never be prompted again.


Other Options

Sort Routines popup


If this is enabled then the character mode routines popup menu, invoked with the key, will always be sorted into alphabetic order, rather than line number order.

Find timeout

When searching a large tags database, it can take time to do the search. The water mark values are used to limit the amount of time and memory a search can take when lots of tags are available. The find timeout is used to limit the elapsed time that a search can take. If a search takes too long then you will be prompted to abort the search.

A project is a way of setting up a collection of options, attributes and files, which collectively form a work area. Traditionally, a project is the high level unit of work in which you are operating. In the context of a tool such as CRiSP, a project is a high level view of a suite of files which collectively are used to create an end product.

CRiSP supports a variety of options for configuring according to your own personal taste. These settings are stored in a variety of configuration files. You can create separate configuration files, and then switch between them if you want to do this manually.

Projects provide an automatic switching mechanism. One of the key attributes of a project is the collection of files which constitute it. Outside of a project, you simply edit or view single files at a time, with no easy way of collecting files together to perform a single operation. Within a project you can specify one or more files - spread over a variety of directories or folders, which, for example, can automatically be tagged to provide cross-reference information.

The core part of the Projects facility is the Projects menu on the menu bar. This menu provides access to the configuration settings and commands for manipulating a project.

The Project options dialog is the main focus of the project setup mechanism. From this dialog you can set up various attributes of your dialog. The dialog is divided up into a number of sections:

Identification

Allows you to name where the project file is to be stored and to provide a memorable description for this project.

Directories

Specify default directories for the project, e.g. working directory when the project is loaded, include directory when invoking compiles and the tag files for cross-referencing.

Files

Define the files which constitute the project.

Filters

The filters are used in the File Open dialogs. Different people work on projects using different programming languages and scripts. This mechanism lets you customise the dialogs so you can quickly select different classes of files relevant to your project.

Macros

You can specify custom macros to be executed and be made available within the context of a project.

Menu

Allows you to customize the Projects menu by adding custom commands for building, compiling, and invoking your target executable within the project.

Target

Used to specify a key file which is usually the target executable for the project.

Click on the appropriate tab at the top of the dialog to switch between the different pages of options.

The .tpl template files are plain text files. The template file is reminiscent of a Windows .ini file, with sections separated by section headers in square brackets. For example, the following is a very simple example of a template file:

# Demonstration template file

[config]

[if-stmt]

if () then

endif;

The format of the template file is basically some declarations at the top of the file, followed by a series of template expansions. There are two sections at the top of the file which may need to be specified to define attributes of the language, and to allow recursive templates to be included.

Comments

You can place comments in the file by starting the line with a hash character (#). Only place comments at the top of the file, before the [config] section.

[config] Section

The config section is used to specify attributes about the language described in this file. The configuration section should appear at the top of the file, below any comments and before any of the template sections.

In the case of programming languages, most language are very similar with only small aspects of their syntax differing. These configuration options are designed to cope with these differences.

The following options are currently available:

case_independent

When you type in a template prefix, this instructs the template matching code to accept upper or lower case matches. For example, the C language is case sensitive, so you wouldn't necessarily use this option.

SQL based languages usually accept mixed upper or lower case as being equivalent, so for example typing "cre" and "CRE" might be acceptable ways of matching the "create table" template.

use_last_token

If this option is specified, then when CRiSP searches for a template expansion, only the last word on the current input line is used to match. Without this option, you cannot perform template expansion if multiple words are on the line; for example, the IDL template uses this so that an inner IF-ENDIF statement can be expanded after an ELSE clause.

[include] Section

The include section allows you to recursively include another template file. Typically this would be useful for languages which are all C based but provide extensions. Rather than replicating the base templates for such entities as if/switch/struct in each file, you can create files which contain only the changes and include in the base file.

For example CRiSP provides an Objective-C template file which simply includes the standard C template file and adorns it with Objective-C specific additions.

The format of the filenames is either a full qualified filename, or a template file language name. For instance “fortran” on its own would cause CRiSP to search for a fortran.tpl file in the standard installation and user customization directories.

Template definitions

The remaining sections in the template file are template expansions. Each template expansion is introduced in its own section and starts off with something like:

[abbrev-stmt]

The name of the template is given in the square brackets. The template must end in a hyphen followed by "stmt" in order for it to be recognized as a possible template expansion. The actual abbreviation is the part preceding the "-stmt". In the example above, the template abbreviation is the string "abbrev". Depending on the setting of the Minimum abbrevs field in the language editing modes dialog box, you would type "a", "ab", "abb", "abbr", "abbre", or "abbrev" followed by a space or tab character to get the expansion.

When a matching template is found, all the text within the template definition section is inserted into the current buffer at the current cursor position. The current indentation level is preserved, e.g. making it possible to type in nested template expansions.

The text making up the template expansion can contain commands as well as literal text to be inserted. These commands can be used to position the cursor after the template has been inserted, or handle user preferences.

You can use tab characters in your literal text expansion quite freely. CRiSP will automatically perform the appropriate tab action, such as honouring the user's soft/hard tab settings.

Template expansions

All template commands are enclosed in $ to separate them from the surrounding literal text.

BEGIN

Inserts the keyword BEGIN. By using $ rather than a plain 'BEGIN', CRiSP will honour your bracket style settings.

END

Same as BEGIN but inserts the keyword END.

BEGIN< END

Same as BEGIN and END above, but inserts a lower case 'begin' or 'end'

OPEN_BRACKET

Inserts an open curly brace and honours the user's bracket style.

CLOSE_BRACKET

Inserts a close curly brace, honouring the user's bracket style.

BLOCK_CUT

If a region is selected before the paste operation then the block is deleted and saved, ready for insertion with a

BLOCK_PASTE

expansion. This allows you to implement a mechanism to enclose a selected region with a template, e.g. when doing HTML template expansions.

BLOCK_PASTE

Paste in the previously deleted region referred to by BLOCK_CUT.

CURSOR

Positions the cursor at this point after inserting the template.

DATE

Insert date in the form dd-Mon-YYYY.

FILENAME

Insert name of current buffer.

END_DEF

Used to mark the physical end of the template expansion. Without this, you can end up with an extra newline after the expansion. Under some circumstances, this is not required, e.g. when performing a template expansion around a block of text. Place this definition at the end of the definition, before the newline and everything after this keyword will be ignored.

INDENT

Use this command to act as if the key was pressed. This honors the users tabs or spaces only mode of operation.

MARK .. MARK_END

The text between the MARK and MARK_END commands is highlighted after inserting the template with the cursor position at the MARK point. This allows you to highlight a syntax element, e.g. $$ and as soon as the user types a key to insert text, the selected region will be deleted.

SHELLVAR

This command is used to execute an external command and provide access to the output from the command. The output is stored in a variable, which can subsequently be referenced via the VAR expression.

The format is:

${SHELLVAR:var:command}

For instance:

${SHELLVAR:todays_date:date}

${VAR:todays_date}

SPACETAB

Insert spaces enough to reach next tab stop.

TOP_OF_BUFFER

Move cursor to start of buffer.

UNINDENT

Moves to the previous tab stop. This can be useful where you want to insert tabbed data but want to leave the cursor in the middle of the line on a tab boundary.

VAR

This command is used to refer to a previously defined value, e.g. from the output from the $ expansion. The value is looked up and inserted into the template at the point the variable is mentioned.

The template files are normally located in the crisp/src/template directory. The template text files have a .tpl file extension. You can create your own private variants of existing templates, or create your own private templates by creating files in the src/template directory in your configuration directory. CRiSP normally stores its configuration files in the directory $HOME/.CRiSP.


If you create a sub-directory: $HOME/.CRiSP/src/template, and place your own template files in there, then these templates will be accessible by the Setup dialog boxes and for use in editing your files. Some things you may want to achieve may not be describable by a simple template file. CRiSP allows you to create a macro to extend the capabilities of the template infrastructure.


For example you will see in the directory crisp/src/template a file, verilog.cr which is provided as an example of how to create a template extension macro. Compiled template extension macros should reside in the crisp/macros/template directory or somewhere locatable in your path, or should be preloaded using CRiSP startup macro mechanism.


Your macro should have the same name as the template file, e.g. verilog.cr and verilog.tpl. Inside the macro file should be a function called verilog_template_handler (or the equivalent for your own language). This template handler macro is called by the template mechanism to intercept various aspects of the template action. You simply need to code the things of interest to you, and ensure they are only triggered by the appropriate action by the user. For example, you wouldn't normally want templates to be expanded when handling the key. The template handling macro is called with a reason code indicating why the template macro is being called. The sample verilog.cr macro file, simply handles space or tab expansions, and ignores all others.


This area is subject to change and future versions of CRiSP are likely to provide more reasons for the callback to be invoked. If you are interested in coding your own template macros you should consult the sample template files and directories.

CRiSP supports over 50 different programming languages out of the box. New support for a language can be added using a point & click mechanism. You can also contact support@crisp.com if you need support for an unsupported language. Language support is provided in 5 distinct areas:

a) Context sensitive colorization

b) Autocompletion, tagging, code completion

c) Infotips - Dynamic help

d) Inbuilt template editing

e) Integration with compilers, linkers etc.

Sample of supported programming languages are:

4gl

accell

ada

aml

arm

asp

awk

basic

bat

c

cfg

cfm

cfscript

chill

cobol

color

compile

cpp

crisp

csharp

dbase

delphi

diff

docbook

dsp

dtd

eclipse

eiffel

forth

fortran

fortran90

html

idl

jam

java

javascript

jpl

jsp

kwd

lisp

mail

makefile

matlab

mips

modula3

none

objc

orasql

pascal

perl

php

progress

pscript

pvwave

python

rc

rebol

roff

rpcgen

rtf

ruby

s29

sas

sgml

shell

sparc

sql

sqr

tcl

tex

vbscript

verilog

vhd

vim

vslick

xbase

xml

xpm

yacc

zsh

This dialog is used to selectively load some or all of the files in a project.

The main list shows all the files defined in the project. Select the entry or entries you wish to load. The convenience buttons at the right allow you to select all files, or to deselect all files.

Open

Load the selected files into CRiSP for editing and/or viewing.

Invert

All files which are selected are deselected and vice versa. Useful when there are just a few files you do not want to load, and it is easier to select them and then invert the selection rather than explicitly selecting all items.

Select all

Select all files. Click on Open to load the files into CRiSP.

Select none

Deselects all files.

The Filter field located below the main file list allows you to selectively display only files matching certain types. Use the combo box to select common files types or type in the wild card appropriate for you. You can use semi-colons to delimit matching files.

For example

*.c;*.h;*.cpp

could be used to match all C/C++ or header files.