Drew Adams <address@hidden> writes:
>> Here are the packages that are eligible for deletion in Emacs 25 (all
>> obsolete since before Emacs 24):
> 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?
Actually, after a few minutes of looking at customize, I see there is both customize-saved (to customize everything the user has customized with customize) and customize-rogue (to customize everything else that is customized outside of customize). These should, hopefully, solve your use-case. Does it?
> 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.