Re: A proposal for removing obsolete packages

[Andrew Hyatt <ahyatt@gmail.com>]

Drew Adams <drew.adams@oracle.com> writes:

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

I hadn't used options before, but I tried now.  I guess I don't see the
usefulness of the command.  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).  But list-options instead gives much,
much more than that in a buffer 38k lines long.  What is the use of
this, and why is it more useful than, say, customize-browse?

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