On Sat, Jan 23, 2016 at 8:02 PM Andrew Hyatt <ahyatt@gmail.com> wrote:

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

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