bug#17832: 24.4.50; `apropos-library' behavior for a top-level library file

[Drew Adams <drew.adams@oracle.com>]

> > Rather than just saying that the command is misnamed, or the name is
> > misleading, the first part of this bug report is to request that the
> > command live up to its name: give you a report of the functions and
> > variables defined in the _whole library_, recursively including those
> > of its required component libraries.
> 
> Many libraries will then appear to define all the CL macros&functions.
> To do a better job, we'd need to distinguish the case where it
> "requires" some other library for internal use compared to the case
> where it requires a file which is conceptually part of the same library
> (just split over several files).

Yes.

And make the recursive behavior optional.  E.g., `C-u' for recursive,
and a button in the top-level output that refreshes the output after
descending recursively.

Additional feature: Since the top-level output lists the required
libraries, make each library name a link/button which if followed
descends into that library (non-recursively, or recursively with
C-u).  IOW, let users drill down manually, a level at a time or
recursively.  (This should be in addition to the possibility of
one-fell-swoop recursive descent at the top level.)

> The most common case, AFAICT, is the first, so I think in doubt
> it's better to assume "requires" aren't really part of the library.

Or have an option that lists libraries to exclude, whose default
value includes all libraries distributed with Emacs.  That gives
users reasonable control over the behavior.