🚀 go-pugleaf

xxxxxxx

Can anyone give me details on the "features" of refer?
We are finding some idiosyncratic behaviour, mainly 
related to how keywords are handled.

I think the following is true (I wish it weren't):
	1. In the set of keywords derived for any 
	one reference, no keyword may repeat (note
	max. 6 letters are used, so Program and
	Programming together will cause trouble)
	Search will result in something like
	No such paper: networ system unix chesso operat system 

	2. Even stricter, I think no keyword may be
	a string that is a substring of another! So keys
	refer and References together will cause trouble. 

When considering the space of references,
each of which is accessed through an unordered set
of keywords, there will be trouble unless strict
control of all sets is maintained:

	3. No set of keywords should be a subset of
	that for another reference.  On a search using
	the smaller set, both references may be found, 
	and the first occurring printed - which may
	be the wrong one. The larger set will find
	the correct reference (but if you introduce
	such an error by adding a new reference, you
	might not notice it until somebody reformats
	an old document to include the newly false 
	pointer!)	

	4. If too few keywords are specified, and too
	many references result, there is a typical
	UNIX-style error message and no more:
		Bus error (core dumped)
	or	Assertion failed: file refer2.c, line 84
	I don't know what the "ok limit" is.

For an example, combine the lists Rbstj and Rv7man in
/usr/dict/papers and try to get all references printed.

Such problems occur almost every time I update our database
with new references. Some of the problems may arise with my
automatic generation / reference system check. But it would
be nice to be informed that my (BSD4.2) refer has been improved,
or that some better checking method exists.

Is there a way to overcome the date-handling neatly? I would like
to use a date like "1986.01.23" as a search object.

On other topics: we have severe requirements for technical documentation
here (the structure is more important than the content, at least to me!).
(This may be typically European; certainly we need "industrial quality")

Using most WYSIWYG editors is like drawing a building design
without lifting your pen from the paper, like producing one-off
automobiles before the assembly-line was discovered! 
I'm not very interested in word-processing or type-setting: 
but we need all the help with "document-processing" that we can get.
We need and use several types of automatic document-handling tools.
(I'll tell you about what we've done when I get the time)!

-- graham tritt
  mcvax!cernvax!hslrswi!graham
  Graham Tritt,
  Postfach 302,				I'm looking for a cutie
  3000 Berne 25,
  Switzerland.