REF REFFORM John Gibson, Jun 1987
Revised: A.Sloman, Jan 1990
Revised: A.Howard, Jul 1990
Revised: D.McIntyre, May 1993
COPYRIGHT University of Sussex 1993. All Rights Reserved.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<< THE FORMAT OF REF FILES >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
This file specifies the format for REF files which Sussex uses and
recommends, listing various procedures to help adhere to these
standards. Note that from Version 14.22 of Poplog onwards, the system
REF files have taken on a new look. This file details the new standards
that accompany that look.
When it comes to writing your own REF files, you can of course stick
to the old style. Details of the old style are now in REF * REFFORM_OLD
CONTENTS - (Use <ENTER> g to access required sections)
1 Introduction
2 The REFORMAT Program
3 Format of REF Files
3.1 Example Template REF File
3.2 The Header
3.3 The Title
3.4 The Overview
3.5 The Contents
3.6 Sections and Section-Header Formats
4 Table Format
5 Paragraph Format
6 Verbatim Text
7 Program Code
8 Lists
8.1 Enumerated Lists
8.2 Bullet Lists
8.3 Descriptive Lists
9 The Use of VED Character Attributes
10 Quoting Things
11 Identifier Entries
11.1 Example identifier entries
11.2 Standard Type Names for Arguments/Results
... Basic Types (Excluding Numbers)
... Numbers
... Other types
... Prolog types
12 Useful utility procedures
13 Further Documentation
---------------
1 Introduction
---------------
This file sets out the standard format for Poplog REF files. This format
is used by the library program LIB * MKREFINDEX (which builds an index
of the identifiers documented by a set of REF files.)
For more general information on formatting online documentation, HELP
and TEACH files, libraries, etc. see HELP * STANDARDS
-----------------------
2 The REFORMAT Program
-----------------------
After Poplog 14.22 there will a program in existence called REFORMAT.
The purpose of this program is to enable the user to automatically
create a hard copy manual from the REF files. This is done dynamically
using the most current edition of a REF file. The programs uses the
various standards laid out in this file to divide a given REF file into
text blocks which it then wraps in LaTeX code. More details of the
workings of the program are given in REF * REFORMAT and HELP * REFORMAT
It is crucial to the workings of this program that each REF file be
acceptable input to the program. There has been no changes in the
standards but there has been a tightening up. For LIB * REFORMAT to work
then the standards specified in this file must be rigorously adhered
too.
The Sussex REF files will already have been prepared for
LIB * REFORMAT. However if you locally change a Sussex REF file you
should make sure that the changes are compatible with the REFORMAT
program. A special previewer has been written to enable you to see a REF
file as a potential chapter in a manual. To preview a file using
LIB * REFORMAT do
<ENTER> lib reformat
then
<ENTER> filepreview
Depending on the length of the file, after 2-10 minutes a dvi version of
the file will appear on your screen using xdvi. See HELP * REFORMAT for
more details.
If this previewer does not work on your newly changed REF file, then
you have either discovered a bug in the program or your changes have
slipped up in their adherence to standards set out in this file.
REMEMBER: Small errors which you can get away with on-line become
really obvious when nicely printed out.
----------------------
3 Format of REF Files
----------------------
The overall format (exemplified by this file) is:
<header>
<title>
<overview>
<contents>
<section 1>
<identifier entry>
<identifier entry>
...
<section 2>
<identifier entry>
<identifier entry>
...
...
<footer>
Where no lines extend over 72 characters, and all descriptive text is
right-justified using * ved_jrefmr, * ved_jj or * ved_jjp.
3.1 Example Template REF File
------------------------------
NOTE: the numbers of blank lines between different kinds of entries are
important --- they will be used by libraries like LIB * MKREFINDEX.
REF EXAMPLE John Sloman, Jan 1990
Revised: Joan Doe, Feb 1993
COPYRIGHT University of Sussex 1993. All Rights Reserved.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<< AN EXAMPLE TITLE >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx overview xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
CONTENTS - (Use <ENTER> g to access required sections)
1 First Section
...
----------------
1 First Section
----------------
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx text xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxx more text xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
table/program code/list
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxx more text xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
table/program code/list
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxx more text xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<identifier entry 1>
<identifier entry 2>
<identifier entry 3>
<identifier entry 4>
-----------------
2 Second section
-----------------
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx text xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxx more text xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<identifier entry 1>
<identifier entry 2>
<identifier entry 3>
<identifier entry 4>
+-+ C.all/ref/example
+-+ Copyright University of Sussex 1993. All rights reserved.
3.2 The Header
---------------
The header should specify the name of the REF file, and it's author(s)
as shown in the template given in the previous section.
3.3 The Title
--------------
The title should be enclosed in a box made from `>` and `<` characters
as shown in the template. Please make sure that the title is:
¤ Meaningful
¤ All in upper case
Please ensure that the width of the box used to enclose the title is the
same as that used in the template (this is used by LIB * REFORMAT.) More
than three lines can be used for long titles.
3.4 The Overview
-----------------
This should act as a very brief synopsis of the contents of the REF
file. There should be no blank lines between paragraphs. See the
template for an example.
3.5 The Contents
-----------------
The contents are an (optional) index of the REF file as produced by
* ved_newindex. Sussex REF files are produced using the "sp" style of
index. See * ved_newindex for details.
3.6 Sections and Section-Header Formats
----------------------------------------
The main text of the REF file should be divided into sections and
sub-sections to aid comprehension.
¤ Each (sub)section should have a heading.
¤ There should be 2 or more empty lines preceding a sub-sub-heading, 3
preceding a sub-heading, and 4 preceding a main heading.
¤ There should be one blank line after main headings, and no blank
lines after other headings.
Headings should be produced with * ved_newheading to conform to the
format used by * ved_newindex. The three heading types used are:
-------
1 Bold (Main Heading)
-------
1.1 Non-Bold (Sub Heading)
-------------
... Non-Bold (Sub Sub Heading)
-------------
Note that:
¤ Underlining and overlining is the same length as the heading text
¤ Headings should start at column 1
¤ Underlining is made of `\G-` characters
¤ There are two spaces after the section number (or '...')
See REF * REFFORM_OLD for details of the old heading and section
formats.
---------------
4 Table Format
---------------
Tables are recognised by each column having an underlined heading. The
underlining must be the SAME LENGTH as the heading. The underlining can
be made up of ordinary hyphens or `\G-` characters.
There should be a blank line before and after the table.
Each column should be left justified (ie. aligned with the first column
of the heading.)
If there are going to be columns where entries will be omitted, make
sure a row containing an entry for each column is the first row. Without
this LIB * REFORMAT will not work properly. If this is impossible place
a hyphen (`-`) in the non-filled columns to indicate a blank entry.
-------------------
5 Paragraph Format
-------------------
These follow the form of the template. Two rules should always be
followed:
¤ Make sure that all regular paragraphs are right justified.
¤ Single line paragraphs should not have more than two contiguous
spaces to prevent them being interpreted by LIB * REFORMAT as an
itemised list."
----------------
6 Verbatim Text
----------------
Text that should be reproduced verbatim by * REFORMAT should have the
VED format-control space character `\Sf` placed at the beginning of
every line. For example:
Col:1 4 8 12
| | | |
X This text
X should be
X reproduced
X verbatim
(where `X` represents `\Sf`.)
There should be a blank line before and after the verbatim section. The
command * ved_ifsp can be used to insert format spaces, and the command
* ved_dssp can be used to view them.
---------------
7 Program Code
---------------
For compilable sections of code the ved prompt-marker space `\Sp` should
be placed at the start of every line. For example:
Col:1 4 8 12 16 20 24 28
| | | | | | | |
X vedcurrent.sys_fname_nam=>
(where `X` represents `\Sp`.)
As with all other text groups there should be a blank line on either
side.
`\Sp` should only be used for program code that is actually compilable,
i.e. not just 'outline' or 'meta' examples. If in doubt treat as
verbatim text and use `\Sf`.
As for verbatim text, * ved_ifsp and * ved_dssp can be used to insert
and view prompt-marker spaces.
NOTE: The LIB * REFORMAT program has to use some character to mark the
beginning and end of program code. The `?` character was selected for
this purpose. Therefore, try not to use the `?` character in code or if
you have to, please try to put it on the end of a line.
--------
8 Lists
--------
There are three types of lists.
¤ Enumerated
¤ Descriptive
¤ Itemised (bullet)
Lists can be embedded in each other. If this is the case then it is best
to indent the sublist.
Although you are able to have non-indented lists, the LIB * REFORMAT
program performs better if they are indented.
8.1 Enumerated Lists
---------------------
These take the form:
N text text text text text text text
text text text text text text
N text text text text text text text
where N is a number bullet in the form of one of: 1. (1) (a) a) a.
8.2 Bullet Lists
-----------------
These take the form:
B text text text text text text text
text text text text text text
B text text text text text text text
B is one of `¤` (`\G#`), `o`, or `*`. The use of `*` is not recommended
as it can lead to confusion with cross references.
8.3 Descriptive Lists
----------------------
These take two forms. For short snappy lists do::
ITEM text text text text text text text
ITEM text text text text text text text
For longer, more informative lists do:
ITEM
text text text text text text text
text text text text text text text
example of code/table
text text text text text text text
text text text text text text text
text text text text text text text
ITEM
text text text text text text text
text text text text text text text
text text text text text text text
text text text text text text text
ITEM
text text text text text text text
text text text text text text text
example of code/table
text text text text text text text
text text text text text text text
(ITEM can be in lower or upper case.)
Sometimes when you are making a list, it can look better as a table. If
this is the case then please convert it. The hard copy version produced
by LIB * REFORMAT will definitely look better.
--------------------------------------
9 The Use of VED Character Attributes
--------------------------------------
The use of the VED character attributes in REF files is perfectly
acceptable. You can use them to emphasize pieces of the text. The
following general rules are used in Sussex REF files:
¤ Identifier names are placed in bold text (eg popmemlim.)
¤ Variables are placed in italics and are usually lower case (eg
item.)
¤ Descriptive list items are placed in italics.
¤ Cross references to other on-line documentation should be italicised
too i.e. REF * REFFORM, except when they are to identifiers (eg REF
* ved_chat) when the identifier should be bold. The `*` is not
attributed.
You can use ved_chat to change the attributes of a word. See * ved_chat
for more information on VED character attributes.
------------------
10 Quoting Things
------------------
Just some simple rules which should be observed as a matter of course.
¤ Use the (") character to quote words. Do NOT use a character quote
to begin the word and a string quote to end it.
¤ Use the character quote (`) to quote characters
¤ Use the string character (') to quote strings.
¤ If you are referring to a named section, enclose the reference in
double quotes (").
¤ Make sure that if you open a double quote on a word then you end it.
i.e do not write "ref'. It is okay to have single " in verbatim code
however or enclosed in character quotes or brackets.
----------------------
11 Identifier Entries
----------------------
The important things are:
1. No entry should contain MORE than 1 consecutive blank line, and
each entry must have ONLY 2 blank lines before and after it.
2. An entry begins with one (or more) "synopsis" lines, each
starting at column 1, and the first of which for each new
identifier has that identifier's identprops enclosed in square
brackets at the end of the line (right justified to column 72.)
To save space, "constant" is omitted in combination with
anything else, and the only type that should be given is
"procedure" for a procedure identifier (Poplog doesn't have any
typed variables other than procedure-type, so this part
shouldn't imply otherwise.) These lines can be inserted with
* ved_idprops. The main text of the idprops should be in
bold-italics, with the square brackets in normal text. Examples
are:
[procedure] (= procedure constant)
[procedure variable]
[constant]
[variable]
[operator N]
[syntax]
[syntax N]
[macro]
[macro variable]
For a variable, it should also say if protected, e.g.
[protected procedure variable]
[library] is also used to flag the name of a library that must
be explicitly loaded.
3. Synopsis lines represent the following items:
¤ An outline use for syntax words.
¤ An outline call for procedures (and their updaters) with
arguments and results.
¤ Example assignments to and from items for ordinary
variables.
¤ Example assignments to items for protected variables and
constants.
¤ Just the name for anything else
If a synopsis lines extends over more than 1 line, the
continuation lines must be indented by any number of columns
(OTHER THAN 8 columns to distinguish them from the body of the
text.) Note that the [identprops] part must still be on the
first line of that synopsis.) See examples below.
4. As implied above, each entry can contain multiple synopsis
lines, either for different call forms of the same identifier,
or for several identifiers, but [identprops] at the end of the
line must mark the first one for each new identifier introduced.
5. Formal parameter names in synopsis lines should only be made
up of italicised lower case alphanumeric characters and
underscores.
6. The first line of the following text for the entry must start at
column 8; the rest of lines must be indented by at least 8
columns (and mustn't contain 2 or more consecutive blank lines.)
7. As a general room everything on the synopsis line should be
bold, with two exceptions:
¤ Variables which should be in italics.
¤ Text which is not typed used to indicate option arguments
(which should be in normal text.)
See the example identifier entries in the next section.
11.1 Example identifier entries
--------------------------------
(In the examples that follow, the entries have been indented by one
character to prevent confusion with actual entries in REF files.)
col 8 col 72
| |
newanyproperty(assoc_list, tab_size, expand_pow, thresh, [procedure]
hash_p, equal_p, gc_type,
default, active_default) -> prop
This is for constructing more complex properties. It returns a
new property prop, where the arguments are:
subscrs(n, string) -> char [procedure]
char -> subscrs(n, string)
Returns or updates the n-th character char of the string string.
num_1 + num_2 -> num_3 [operator 5]
num_1 - num_2 -> num_3 [operator 5]
num_1 * num_2 -> num_3 [operator 4]
num_1 / num_2 -> num_3 [operator 4]
These operators respectively add, subtract, multiply and divide
their arguments, which may be any numbers. The type of the
result depends on the rules of floating-point and complex
contagion (etc, etc.)
popradians -> bool [variable]
bool -> popradians
This boolean-valued variable specifies whether the angle
arguments or results for trigonometric procedures are in radians
(true) or degrees (false.) Note that the default is false,
implying angles in degrees.
pi -> float [constant]
This constant is the best ddecimal approximation to "pi".
popexecute -> bool [protected variable]
This boolean variable is true when the current invocation of
the VM through sysCOMPILE is at execute level, and false
when code is being planted inside a procedure or a non-executing
lblock.
11.2 Standard Type Names for Arguments/Results
-----------------------------------------------
The following names can be used for arguments and results of the
appropriate type: they are not meant to be compulsory, only for cases
where the use of more descriptive "semantic" names isn't warranted (or,
they can be used in combination with the latter.)
They are also not meant to be rigorous in the sense that a given
argument or result can only take the implied value, but show that this
is its "principal" value (any exceptions being clearly described in the
text.)
Where more than one is used, add integer subscripts at the end, i.e.
item_1, item_2, etc.
Alternatively if there are different type characterisations add prefixes
separated by underscores, e.g. s_vec and d_vec for start vector and
destination vector in REF * move_subvector
See REF * DATA for information on the data types built in to Poplog.
... Basic Types (Excluding Numbers)
-----------------------------------
array [datatype]
An array. See REF * ARRAYS
bool [datatype]
Boolean: true or false. Note that any non-false value is treated
as being true in most circumstances.
char [datatype]
Character: an integer between 0 and 255. Note that Poplog uses
the ASCII standard.
clos [datatype]
Closure: procedure built by partial application. See
REF * PROCEDURE/Closures
dev [datatype]
Device: structure used for file and terminal I/O. See
REF * SYSIO
external_p [datatype]
External procedure: created by external_load.
fvec [datatype]
Standard full vector.
ident [datatype]
Identifier. See REF * IDENT
intvec [datatype]
A vector of 32-bit signed integers.
item [datatype]
Any Poplog object at all.
key [datatype]
Class-descriptor. See REF * KEYS
list [datatype]
A list of items (or the empty list, nil.) See REF * LISTS
p [datatype]
Procedure.
pair [datatype]
A pair: two-element record structure used, among other things,
for building lists.
proc [datatype]
A process: a data structure created (e.g.) by consproc recording
the state of execution of a procedure. See REF * PROCESS
prop [datatype]
Property: a hashed data structure associating item/value pairs.
See REF * PROPS
propent [datatype]
Property entry: records a single item/value association. See
REF * PROPS
ref [datatype]
Reference: a one-element record type object. See
REF * RECORDS/References
sect [datatype]
Section: a mapping between words and idents. See REF * SECTIONS
string [datatype]
A vector of characters. See REF * STRINGS
struct [datatype]
Compound object (anything except integers & decimals.) See
REF * DATA
undef [datatype]
An undef record: the value of an uninitialised permanent
identifier. See REF * IDENT/Undef
vec [datatype]
Vector: any vector type object.
word [datatype]
Word. See REF * WORDS
... Numbers
-----------
See REF * NUMBERS for full information on types of numbers available.
n [datatype]
m [datatype]
A simple integer.
int [datatype]
Integral: simple or big integer.
float [datatype]
A floating point number (decimal or ddecimal.)
rat [datatype]
Rational: ratio or integral.
ratio [datatype]
A ratio (fraction.)
real [datatype]
A non-complex number (integer, biginteger, ratio, decimal or
ddecimal.)
complex [datatype]
A complex number.
num [datatype]
Any number at all.
... Other types
---------------
bytestruct [datatype]
A 'byte accessible' data structure. See REF * DATA/Byte
char_cons [datatype]
A character consumer procedure. See REF * CHARIO
char_rep [datatype]
A character repeater procedure. See REF * CHARIO
dir [datatype]
Directory: a string naming a disk directory.
field_spec [datatype]
A record or vector field type descriptor (as used by conskey.)
See REF * KEYS
file [datatype]
A string or word naming a disc file, or a device record
corresponding to a disc file or pipe or mailbox, suitable for
reading or writing.
filename [datatype]
String or word naming a disc file.
idprops [datatype]
An identifier status descriptor (as used by sysSYNTAX.)
item_rep [datatype]
An item repeater procedure, producing a Poplog item each time it
is called, and termin when there are no more items. See
REF * ITEMISE
lib_name [datatype]
Name of a library file. Normally a string, but can sometimes be
a word. See REF * LIBRARY
search_list [datatype]
List of directories in which to search for library programs and
documentation. See REF * LIBRARY and HELP * SEARCH_LISTS
spec [datatype]
Field specification as used for conskey See REF * KEYS/SPEC
spec_list [datatype]
List of field specifications as required for record classes. See
REF * conskey
string_rep [datatype]
An string repeater procedure, producing a string each time it is
called, or termin when finished.
strword [datatype]
word or string.
vedfile [datatype]
A string that is a filename suitable for VED, or a VED file
structure such as is found in vedbufferlist (i.e. a vector of
strings.)
wident [datatype]
word or ident.
... Prolog types
----------------
prologterm [datatype]
A complex Prolog term. See REF * PROLOG
prologvar [datatype]
A Prolog variable. See REF * PROLOG
-----------------------------
12 Useful utility procedures
-----------------------------
The following procedures may be found useful when editing REF files:
¤ * ved_jrefmr is used for formatting REF file identifier entries.
¤ * ved_slrhs can be used to automatically create the updater entries
for REF file synopsis lines.
¤ * ved_idprops is used to insert [identprops] entries in REF file
synopsis lines.
¤ * ved_dssp is used to see the special formatting spaces used by VED.
¤ * ved_ifsp is used to insert and remove the special formatting
spaces used by VED.
¤ * ved_newheading is used to create REF file section headings.
¤ * ved_newindex is used to create a contents page for a REF file.
The normal VED formatting procedures can also be of great use. See
"Formatting Commands" in REF * VEDCOMMS for more information.
Also see:
HELP * VEDBLOCKS
Information on moving blocks of text in VED.
HELP * FORMAT
Commands to aid on-screen formatting of text in VED.
-------------------------
13 Further Documentation
-------------------------
HELP * VEDFILETYPES
Setting the defaults for different types of files.
HELP * MKREFINDEX
Creating an index of REF files that can be used by the * ved_? and
* ved_?? commands
HELP * STANDARDS
Other documentation and library standards for Poplog.
REF * DOCUMENTATION
Implementation of the Poplog on-line documentation system.
+-+ C.all/ref/refform
+-+ Copyright University of Sussex 1993. All rights reserved.