ivi Editing Records

The editor currently manipulates two kinds of object: text lines and records.

A text line is sequence of (displayable) characters. The line may be arbitrarily long, and only a portion appears on the screen at any time. When the cursor "runs off the screen", to the right or left, the editor moves its "window" to display an adjacent portion. (There is an overlap of 19 columns.) The symbols - and/or + in the "flag" columns of the screen indicate that there is more material on the line to the left and/or right respectively.

A record is a sequence of fields, each of which is a sequence of characters. The number of fields and the maximum length of each is set by the user (or by default).

Text lines and records may be mingled within a file, but this is not recommended. It is expected (though not mandatory) that the records within a given file will be homogeneous, that is to say, each will have the same number of fields, and that corresponding fields will be used for similar purposes.

Records can be viewed in either template or text form. In template form only a single record can be seen at one time. Its fields are arranged on the screen inside a template which can be designed and established by the user. The maximum size of each field is shown by ^ symbols, which indicate unfilled spaces. In text form, each record is shown as a single text line, with its fields terminated by | symbols. Several records appear at one time (as in the case of text), and a record can "run off the screen" on to the next adjacent window.

In effect, there are three viewing types: TEXT, RECORD/TEXT and RECORD/TEMPLATE, which the user may specify/alter for each corefile independently. (There are several others which are hangovers from earlier versions of ivi.) The viewing type not only affects the view displayed for an object, but also determines the set of operations available. For example, in RECORD/TEXT view the delete operation works only on records, and does not permit deletion of the | symbol, which would damage the structure of a record. Similarly, with TEXT viewing type selected, editing of records is inhibited, again to prevent structural damage.

The currently selected object type (though not the viewing type) is shown at the top right of the screen.

The ability to edit records is one of the more powerful interfaces between ivi and vinci, since all vinci grammars will include lexical materials, and development of a grammar will usually entail much back and forthing between lexicon editing and generation.

Editing records is not much different from editing text, and much of this has already been covered under Typing Operations. This webpage covers some extra information, as well as discussing record templates, field assignments and extended record checks.

A record is a sequence of fields, each of which is a sequence of characters. A file usually contains a collection of records which are homogeneous to one another in regard to the number of fields and the type of information which each field holds.

The user can specify the number of fields and the maximum size of each, and can restrict the kinds of characters which each field can contain. These are initialized by default, but are changed when the user installs a record template.

It may be helpful to know that a record is represented internally within ivi by a line of text containing the characters of the fields in order, each field (including the last) being terminated by a | symbol. The internal "line header" also contains information which flags this as a record (as distinct from a text line, or some other object), and this is shown on the screen in either text or record/text view by the two characters \r in the flag columns. Note that the \r sequence is not actually present in the line (nor are the ^ symbols which mark empty character positions in record/template view).

For a line flagged as a record, ivi tries to prevent a user adding or deleting the bar symbols, though there are indirect ways to do this if a user needs to.

When records are stored to a disk file, ivi precedes them with actual symbols \r. When ivi fetches a file, it interprets \r at the start of a line as marking a record; thus it removes them and sets the line header appropriately.

We have already noted that records may be viewed and edited in either record/text or record/template view.

In record/text view, each record occupies a line, and several records are seen at a time. In fact, you are looking at precisely the internal representation just described. The editing operations are very similar to text editing operations, but are interpreted in the context of records. So, as we have noted, you will be unable to insert or delete bar symbols; a character inserted into an already full field causes a character to be lost before the next bar, and so on.

Many users prefer the record/template view. In this case, a single record is shown on the screen at any time, with its fields embedded in a template. The positions and sizes of the fields are shown by rows of ^ symbols. Similar editing operations are provided. A cursor can be moved from character to character, from field to field, and from record to record, and characters can be typed, inserted or deleted at the cursor position.

The template, which can be used to label the fields or give instructions to the typist, is not part of the file itself. It is merely a screen adornment which can be specified in, and installed from, an independent text file. Alternative templates can be used for the same record file, so that the same data may be viewed differently on different occasions. Or a user can switch back and forth between record/text and record/template views.

A wide range of operations is provided to manipulate records. A few are described here. The reader is also referred to the sections on searches, merges, selective fetches, checks, sorts, and so on.

Command: OBject

Purpose: Set the current object and view type

Format: OB <digit>

Parameter: There are now three types:

The remaining types are defunct, though the command may still allow you to enter them.

The object and view type is specific to a corefile; in other words, changing it in one corefile does not affect the type in any other.

Record Templates

Command: TEmplate

Purpose: Install a record template

Format: TE 1|filename

Parameters: filename is the name of a contains a record template file. The first parameter is actually a digit with value 1 (or 0). If it is 2, the command specifies a long merge template. (See Merging Text)

A record template file serves two purposes. It determines the screen positions and labelling of the fields of a record (i.e. the actual template in which the fields are embedded), and it also specifies the number of fields, their maximum sizes and the kinds of characters permitted. A sample template file might be:

    Name:      #1/20
    Address:   #2/35
               #5/15     {c45} postal code

    Phone:     #6/15     {c45} include area code
    {r12,c9}All applicants must complete form.

leading to a template in the form:


Roughly speaking, the template file depicts the template. It contains directives ({c45}, #6/15, etc.) and the template text itself.

Thus, directive {r2} sets a conceptual pointer at the start of line 2 of the template area. (This is actually line 3 of the text zone; the first line of the text zone is reserved.) The new lines and the characters themselves adjust this pointer. Hence Name:, which is part of the template text, is to go at the start of line 3 of the template. The directive #1/20 indicates the position and maximum size of field 1. It will be on line 3, starting in column 12, and will have maximum length 20. The 20 character positions are indicated by the ^ symbols. Similarly, Address: goes at the start of line 4, and field 2, which is allowed 35 spaces, begins in column 12 of that line. Later, {c45} moves the conceptual pointer to column 45 of the current line, and so on.

The directives that may appear in templates are:


The third parameter can be omitted, as can the second and third (but not the second alone).

Braces may be put around field directives if the fancy takes you.

Non-directive text is displayed on the screen at the position of the pointer. Each new line moves the pointer to column 1 of the next line; and each non-directive character moves it one column. Several directives may occur in one set of braces, separated by commas.

Note, incidentally, that record template can easily be edited into a long merge template to print the same kind of record.

What if ... ?

A badly designed record template may give rise to several problems which ivi does not check. Generally these spoil the display, but do not harm the records in the corefile. In this regard, it is helpful to realize that you are not editing the display, but rather an internal data structure representing the corefile. The display is merely a view of the corefile.

Of course, ivi does everything it can to convince you that you are editing the display. After all, that is what is meant by referring to editors as "what you see is what you get" (wysiwyg). This concept is hard to maintain in record/template view. To see this, consider what happens if the template places field 6 to the left of field 5. If the cursor is on field 5, repeated use of the right key moves it to field 6, i.e. leftwards on the display. Field 6 is obviously "to the right" of field 5 in the internal data structure.

What if a field overlaps the right edge of display? It wraps automatically to the next line.

What if the template overruns the bottom of display? The extra lines are overwritten on the bottom line of the text zone.

What if two fields overlap on the display, either because you specified the template this way or because of the two previous answers? In essence, ivi doesn't care, but you probably do. Suppose that fields 3 ("abcd") and 6 ("xyz") occupy exactly the same region of the display; then this region will show whichever of fields 3 and 6 was last displayed (not always field 6). Now suppose it currently shows "abcd", and you move the cursor to appear on the "b"; then internally it may be on either the "b" or the "y", which occupy the same display position. Editing operations will take place at whichever (internal) position the cursor indicates, which may or may not be the one appearing on the screen.

What if you FEtch records which violate the constraints specified in the template? The constraints on the number of fields and their sizes and character types are not checked when you read a file from or store it to disk; they apply only to new records or to existing records being modified. So the records are stored in the corefile correctly, and will ultimately be saved correctly. The display, however, may become contaminated. Excess fields appear at arbitrary places determined by defaults; fields exceeding the maximum size are displayed only up to the maximum; and so on.

Note, by the way, that inserting a character into a field which exceeds maximum length causes one (and only one) character to be lost at the end.

What if you change templates (and constraints) once a record is in the corefile? The answer is the same as the previous one. The revised constraints apply only to further editing.

What if you resize the window and "invalidate" the template? Again the answer is the same.

What if records and text are mixed in the same file? This is a veritable can of worms. The simple answer is that if a text line appears in record/template view, it is displayed on the top line of the text zone and very few record operations (an exception is moving the cursor to the next record) can be performed on it. Conversely, if a record appears in text view, it carries the \r flag in its flag zone, and very few text operations can be performed on it. The situation is more complicated when carrying out sorts, searches, reformats and merges, which run over many lines. This won't be described here. Caveat utilitor!

Record Field Assignments

This facility allows some of the fields of a record to be computed from other fields and entered automatically. It is currently restricted to numerical computations.

Operation: Record field assignment

Purpose: Compute the contents of record fields from values already entered in others

Default Key: ESC $

Operation Number: 51

The operation assumes that a sequence of "assignments" is to be found in corefile 17. These assignments consist of a field to be assigned and a numerical expression template. The operation evaluates each expression in turn and assigns its value to the appropriate field. Later expressions can depend on values assigned earlier. Numerical expression templates are described more fully elsewhere (see Arithmetic).


If corefile 17 contains:


and the current record is 75|65|2| | |, then entering ESC $ assigns field 4 the value (65+75)/2 = 70, and field 5, 70*7.86 = 550.2.

Extended Check

This operation, which is an extension of the Check operation described elsewhere (see Scanning, etc.), can be used on records or text. It allows a user to check the validity of a record or to determine whether some complex occurrence is present at a given point in a text.

Operation: Extended check

Purpose: Compute an "extended check" string for the current record or text position.

Default Key: ESC CTRL N

Operation Number: 24

The operation assumes that a sequence of the Boolean expression templates (see below) is to be found in corefile 18. The expressions are evaluated for the current record (in one of the record views) or for the current position of the cursor in the text (in text view) to produce a string of ones and zeros. 1 indicates that the corresponding Boolean expression is true, 0 false. The leftmost digit of the string corresponds to the first expression.

This "extended check" string is put on the result stack and displayed on the second-to-last line of the display.

The Boolean expression templates, or checks, may involve numbers or strings, and there may be up to 32 of them.

Boolean expression templates involving numbers are a limited class of the numerical expressions templates referred to above and under Arithmetic. The latter may contain the relational operators > , < and = , and the Boolean operators &(AND) and ! (OR). Using these we may construct numerical expressions templates with Boolean values.

The numbered field selectors (#1, #2, etc.) refer to fields of a record (in either of the record views) or words relative to the cursor (in text view). As usual, they are replaced during the check operation by the appropriate record fields or words.

Boolean expression templates involving strings take the form:

$#number=string\string\ ...



asks whether field 3 (or word 3 if the editor is in text view) begins with one of the alternatives "abcd", "pqr" or "xyz".

Boolean expression templates can also used in a FInd command of type 5.


Suppose corefile 18 contains:


asking if

If the current (templated) record is:

    Age:        12^
    Head Size:  6^^
    Married:    yes
    Neck Size:  64
    Shirt Size: 16
    Waist Size: 32

in which ^ denotes an character position as usual, the operation produces extended check string "011", indicating that field 1 is not equal to field 2, but that the other checks are true.

Two commands, the FEtch with its checkpattern parameter present and the FInd of type 6, allow the user to retrieve/locate a record with a particular extended check pattern. Here the user specifies a ternary pattern containing 0's, 1's and ?'s. A record is "good" if its extended check string matches the ternary pattern in regard to its 0's and 1's. The ?'s are interpreted as "don't care"s and match both 0's and 1's. The FInd will also locate a text position.

Note: In a string expression has the form: $#3=yes\no, the check is that field 3 begins with "yes" or "no", which is consistent with the FInd command. If it is desired to check that the field is "yes" or "no", then the formulation should be: $#3=yes|\no| because | matches the field separator.