62 lines
2.6 KiB
Plaintext
62 lines
2.6 KiB
Plaintext
|
# @(#)structures 5.2 (Berkeley) 11/1/93
|
||
|
|
|
||
|
|
There are three major data structures in this package. The first is a
|
||
|
|
single global structure (named GS) which contains information common to
|
||
|
|
all files and screens. It's really pretty tiny, and functions more as a
|
||
|
|
single place to hang things than anything else.
|
||
|
|
|
||
|
|
The second and third structures are the file structures (named EXF) and
|
||
|
|
the screen structures (named SCR). They contain information theoretically
|
||
|
|
unique to a screen or file, respectively. Each SCR structure has a set
|
||
|
|
of functions which update the screen and/or return information about the
|
||
|
|
screen from the underlying screen package.
|
||
|
|
|
||
|
|
The GS structure contains linked lists SCR structures. The structures
|
||
|
|
can also be classed by persistence. The GS structure never goes away
|
||
|
|
and the SCR structure persists over instances of files.
|
||
|
|
|
||
|
|
File names have different properties than files themselves, so the name
|
||
|
|
information for a file is held in an FREF structure which is chained from
|
||
|
|
the SCR structure.
|
||
|
|
|
||
|
|
In general, functions are always passed an SCR structure and often an EXF
|
||
|
|
structure as well. The SCR structure is necessary for any routine that
|
||
|
|
wishes to talk to the screen, the EXF structure is necessary for any
|
||
|
|
routine that wants to modify the file. The relationship between an SCR
|
||
|
|
structure and its underlying EXF structure is not fixed, and although you
|
||
|
|
can translate from an SCR to the underlying EXF, it is discouraged. If
|
||
|
|
this becomes too onerous, I suspect I'll just stop passing around the EXF
|
||
|
|
in the future.
|
||
|
|
|
||
|
|
The naming of the structures is consistent across the program. (Macros
|
||
|
|
even depend on it, so don't try and change it!) The global structure is
|
||
|
|
"gp", the screen structure is "sp", and the file structure is "ep".
|
||
|
|
|
||
|
|
A few other data structures:
|
||
|
|
|
||
|
|
TEXT In nvi/cut.h. This structure describes a portion of a line,
|
||
|
|
and is used by the input routines and as the "line" part of a
|
||
|
|
cut buffer.
|
||
|
|
|
||
|
|
CB In nvi/cut.h. A cut buffer. A cut buffer is a place to
|
||
|
|
hang a list of TEXT structures.
|
||
|
|
|
||
|
|
MARK In nvi/mark.h. A cursor position, consisting of a line number
|
||
|
|
and a column number.
|
||
|
|
|
||
|
|
MSG In nvi/msg.h. A chain of messages for the user.
|
||
|
|
|
||
|
|
SEQ In nvi/seq.h. An abbreviation or a map entry.
|
||
|
|
|
||
|
|
EXCMDARG
|
||
|
|
In nvi/ex/excmd.h.stub. The structure that gets passed around
|
||
|
|
to the functions that implement the ex commands. (The main
|
||
|
|
ex command loop (see nvi/ex/ex.c) builds this up and then passes
|
||
|
|
it to the ex functions.)
|
||
|
|
|
||
|
|
VICMDARG
|
||
|
|
In nvi/vi/vcmd.h. The structure that gets passed around to the
|
||
|
|
functions that implement the vi commands. (The main vi command
|
||
|
|
loop (see nvi/vi/vi.c) builds this up and then passes it to the
|
||
|
|
vi functions.)
|