RE: A proposal for removing obsolete packages

[Drew Adams]

> Here are the packages that are eligible for deletion in Emacs 25 (all
> obsolete since before Emacs 24):
> 
> options

FWIW, wrt `options.el':

1. Command `list-options' lists all user options, together with their
current values and their documentation.

That still seems useful to me.  If it is not, we should tell users
what is its specific replacement.

I see only this in the doc string of `list-options':

  "It is now better to use Customize instead."

("instead" is redundant here, BTW.)

And this message is shown at the top of the `list-options' output:

  "This facility is obsolete; we recommend using M-x customize instead."

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.).

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'.


2. Similarly, I think that command `edit-options' is still useful.

And yes, I'm familiar with Customize, and I use it often.  But I
don't see that it replaces the specific behavior offered by
`options.el'.  If I'm right about `edit-options' not having a
replacement, please consider keeping it too, possibly moving it
to one of the `cus*.el' files.


3. It is true that `edit-options' does not DTRT when an option has
a `:set' function etc.  It simply uses `set' to set the new value.
(This is true also of command `set-variable', BTW.)  To improve it,
we could make it use a Customize function such as
`customize-set-variable', which does DTRT.


4. I might have said the above when `options.el' was considered
for deprecation.  Dunno.

In any case, I've said it now - I don't see why this library needs
to be deprecated, much less removed.  It represents zero maintenance
burden, unless I'm missing something.

Sure, we want to encourage users to use Customize for most of their
user-option needs.  But I don't see the specific features offered
by `options.el' being provided by Customize.  And I think they are
useful features.

For all the user complaints we hear about Customize (and I generally
defend Customize, though I agree that the UI leaves something to be
desired), I do not recall a single complaint about the commands
`list-options' and `edit-options'.  The listing is clear and easy
to use.

Given #3, above, we could decide to keep only `list-options', but I
think a better approach would be to keep both, possibly improving
`edit-options' to take `:set' etc. into account.  Another alternative
would be for the editing keys to just pop to a relevant Customize
buffer for the given option.

`options.el' provides a useful view of the user options.  I think
that such a view is missing with Customize.