Re: Moving packages out of core to ELPA

[Po Lu <luangruo@yahoo.com>]

JD Smith <jdtsmith@gmail.com> writes:

> Maybe I should be more specific here: I don't think the cost/benefit
> favors having it in the core ready to fire up when any .pro file is
> loaded (since there are other unrelated flavors with that file type in
> the wild, e.g. Qt config files, which confuses people)

That's easily resolved, if we judge that this is an issue.

> or having the IDLWAVE manual appear at the top level of M-x info (as
> nice as a manual it is, and as hard as I worked on it lo those many
> years ago).

Likewise.  But if I may digress a little, why should it be ever a
problem that an index or directory contain information of marginal
interest, when that is the rationale for maintaining such a directory to
begin with?  And why is IDLWAVE more of a problem than the remainder of
our eclectic corpus of manuals, many of which are to the average user no
more relevant than is IDLWAVE?  To be found in the card catalog of any
library are the answers to both these questions, as the Info directory's
role is quite comparable to theirs.

The purpose of the Info directory (or any directory, at that) is to
present users with references to all available sources of documentation,
which is rather irreconcilable with the idea of optimizing its
proportions by removing entries that do not interest a sufficient
segment of readers, for a definition of "sufficient" set by whoever
takes charge of the manual.  To this end, the GNU C library places
references to every documented Glibc function in the directory tree, the
scale of which list makes ours seem minuscule by comparison.

Against this background, removing IDLWAVE to clear up space in the Info
directory is an misinformed as well as ineffective gesture at best.

> hand.  A small package that is effectively invisible and never loads
> unless the user summons it has fewer costs in this way of looking at
> it.

This description could also apply to IDLWAVE as it stands in core.