Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!daver!tscs!metran!jay
From: jay@metran.UUCP (Jay Ts)
Newsgroups: comp.unix.sysv386
Subject: Re: '386 Unix Wars
Keywords: sco unix interactive wars
Message-ID: <362@metran.UUCP>
Date: 24 Dec 90 16:22:01 GMT
References: <276d312d-8aecomp.unix.i386@point.UUCP> <33791527@bfmny0.BFM.COM> <1990Dec23.160807.3207@virtech.uucp>
Organization: Metran Technology, Tampa, Florida
Lines: 30

In article <1990Dec23.160807.3207@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:
> In article <357@metran.UUCP> jay@metran.UUCP (Jay Ts) writes:
> >
> >  [flame of permuted indexes deleted]
> >
> >Basically, the permuted index works well only for those with enough experience
> >and knowledge to already know exactly where to look.  If you think there's
> >nothing wrong with having the permuted index as the sole index, then I guess
> >you can take this as a compliment.

> You go on and on about how bad the permuted index is when our real complaint
> (and somewhat justified) is that the one-line description of the manual page
> (which is used to build the permuted index) is not always conceived with
> the thought that it is the basis for the index.

Well, sorry for the verbosity :-), but my complaint really is that the permuted
index is built not from the DESCRIPTION, but the NAME field of the manual page.
Especially for entries like termio(7), which I had used as an example, there are
a number of subtopics in the DESCRIPTION that are not simply and obviously
connected with the vague overview given in the NAME field.

> I would rather see a better description line which would make the permuted
> index even better.  Perhaps a better solution would be to insert a couple
> of different description lines, if appropriate.

Or to have some intelligent software (or a human) look through the DESCRIPTION
part of the manual page and make its own, and then make the permuted index from
that...
				Jay Ts
				uunet!pdn!tscs!metran!jay