Mail Archives: djgpp-workers/2002/03/04/01:04:23
On Sun, 3 Mar 2002, Peter J. Farley III wrote:
> >We could add some info in parentheses, like this:
> >
> > From gccNNNb.zip (The GNU Compiler Collection):
>
> How is that so different from my suggestion:
>
> GNU C programming documentation @strong{From gccNNNb.zip}
It puts the package first, description later, for those who don't know
what gccNNNb.zip is.
If it's not different, how about accepting my suggestion? ;-)
> M:\>info --apropos="selecting text"
> info: No available info files have "selecting text" in their indices.
>
> Now, I realize these failures are because the indices in the underlying
> info files don't have any of those phrases in them, and the indices are
> all that info has to work with. Better indices would yield better
> results.
Indeed. A bug report is in order (IMHO, manuals for Fileutils and
Textutils need a lot of work). You could also try "c--apropos ut" as a
last resort. In general, you should go from the specific to the general
when you are looking for such unknowns. That is, start with something
quite specific to what you want, and if not found, gradually make the
search phrase more and more general (thus potentially getting more false
hits). I'm sure you already know that.
> But do you see why frustration can easily set in?
No. A single example of an unsuccessful search proves nothing except
that this example failed. Especially since a simple "info cut" would
bring you to the Promised Land.
> This is why I must
> disagree with the premise that "/info/dir" is "just a menu". This is
> the place where a person starts to look for information that they
> need.
But that's not how the Info system is designed. It might be that some of
the manuals don't follow the design too well, but most do. You shouldn't
ask for a change in design because of a few bad implementations.
Menus are simply not designed to be an efficient vehicle of search.
> It should be much more than "just a menu". At the very least,
> it should be a very *structured* menu, with what journalism students
> are taught to call the "inverted pyramid" shape: The most general and
> broad information at the top, with more details in the middle parts and
> the most detail at the end.
Info menus are not designed to be like that. They lack hierarchy and
good organizational features. They are simply linear lists of headers,
more or less. So it's hard to organize them for efficient search.
> This is how many reference books are organized, because it works.
The Info equivalent of using a manual as a reference is the index search,
invoked by the `i' command. "info --apropos" is its generalization for
the case where the user doesn't know what manual to look in.
> And I think the idea of a "concept index" for "/info/dir" is not out of
> place. Why shouldn't someone looking for a way to delete certain
> amounts of text from each line of a file have an easier way to find the
> "cut" program?
I woudn't object to adding an index to dir.texi. However, you should be
aware up front that producing a fairly full index for all the manuals,
such that it could replace your abortive apropos search for "cutting
text", is a huge job. My hat off to anyone who does that.
> That is what I think will help both newbies and experts alike.
Newbies and experts alike should IMHO begin by learning about "--apropos",
"--usage", and a few more useful Info switches, and also about the `i'
command. The number of times I had to tell people about those features
is amazing, considering that "info --help" displays all the switches.
There's an enormously powerful tool there for reading and searching the
manuals, but it sounds like it goes mostly unused.
- Raw text -