RE: A proposal for removing obsolete packages

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

> > Really?  Just how do you "use Customize" to get a listing such as
> > `list-options' provides?  How do you use `M-x customize' to get
> > such a listing?
> >
> > I don't think you can get such a listing.  Certainly not with just
> > `M-x customize'.  And `customize-apropos .*' doesn't give you the
> > same thing (no complete doc strings, and not just options, etc.).

Both of those messages are incorrect in what they tell users now.

> > If I'm right that there is no real substitute provided by Customize
> > then I think that command `list-options' (renamed, if necessary)
> > should be kept.  It could be moved to one of the `cus*.el' files,
> > if you really plan to toss `options.el'.
> 
> I hadn't used options before, but I tried now.  I guess I don't see
> the usefulness of the command.

It gives you a readable, searchable buffer of all of the options,
together with their values and complete doc strings.  To me, that
can be useful.  And I don't see that Customize provides any
replacement for it - nothing at all similar, AFAICT.

> What I thought you were described above
> seems useful indeed - a list of everything customized (for those who
> don't want to fiddle with elisp).

A list of everything that you have customized but not saved is a
different topic.  It is not what `list-options' is for.

But FWIW, the command you describe already exists:
`customize-customized' (though it returns info also about faces).

And command `customize-saved', if by "customized" you meant
customized and saved.

> But list-options instead gives much,
> much more than that in a buffer 38k lines long.

Yes.  It is not about options that you have customized - that's
a different topic.  And it's not just about listing all of the
options with one-line descriptions.  It's about what `list-options'
does: lists all options together with their current values and
complete doc strings.

> What is the use of this, and why is it more useful than, say,
> customize-browse?

See above for the usefulness.

There is no reason to compare it with `customize-browse' - that's
irrelevant, unless you are claiming that it provides the same
functionality and so is a replacement.

Just because `customize-browse' can be useful is no reason that
`list-options' cannot also be useful.

Similarly for `customize-apropos-options', which is more like
what `list-options' does (with a regexp of `.*').

And you cannot search across all (complete) doc strings with
`customize-apropos-options' - you need to open each entry
individually, to see its full doc string.

(Isearch could perhaps be modified to automatically open
`customize-apropos*' entries that have search hits, instead of
ignoring text in closed entries.  But that's not the case today.)

Anyway, you need not find the command useful for it to be useful
to others.  (There are people who do not find `customize-browse'
to be particularly useful...)

Try `apropos-documentation', which is not about options, but
which is another buffer that shows you complete doc strings,
across which you can search etc.  Useful, no?

An improvement to `list-options' could be to have it list only
matches for some apropos input.  But even now by listing all
options it can be useful.

If the `customize-apropos*' commands were improved to show
what `list-options' shows (searchable full doc strings and
current values) then `customize-apropos-options' might provide
a replacement for `list-options'.  But that's not yet the case.