[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A proposal for removing obsolete packages
From: |
Andrew Hyatt |
Subject: |
Re: A proposal for removing obsolete packages |
Date: |
Sat, 23 Jan 2016 20:02:09 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) |
Drew Adams <address@hidden> 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.
- Re: A proposal for removing obsolete packages, (continued)
- Re: A proposal for removing obsolete packages, John Wiegley, 2016/01/20
- Re: A proposal for removing obsolete packages, Andrés Ramírez, 2016/01/20
- Re: A proposal for removing obsolete packages, John Wiegley, 2016/01/20
- Re: A proposal for removing obsolete packages, Eli Zaretskii, 2016/01/20
- Re: A proposal for removing obsolete packages, Andrés Ramírez, 2016/01/20
- Re: A proposal for removing obsolete packages, Eli Zaretskii, 2016/01/20
- Re: A proposal for removing obsolete packages, Andrew Hyatt, 2016/01/23
- Re: A proposal for removing obsolete packages, Richard Stallman, 2016/01/20
- Re: A proposal for removing obsolete packages, Andrew Hyatt, 2016/01/23
- RE: A proposal for removing obsolete packages, Drew Adams, 2016/01/23
- Re: A proposal for removing obsolete packages,
Andrew Hyatt <=
- Re: A proposal for removing obsolete packages, Andrew Hyatt, 2016/01/23
- RE: A proposal for removing obsolete packages, Drew Adams, 2016/01/23
- Re: A proposal for removing obsolete packages, Andrew Hyatt, 2016/01/24
- RE: A proposal for removing obsolete packages, Drew Adams, 2016/01/24
- Re: A proposal for removing obsolete packages, Richard Stallman, 2016/01/24
- Re: A proposal for removing obsolete packages, Andrew Hyatt, 2016/01/24
- Entering Unicode characters, Richard Stallman, 2016/01/25
- RE: Entering Unicode characters, Drew Adams, 2016/01/25
- Re: Entering Unicode characters, Stefan Monnier, 2016/01/25
- Re: Entering Unicode characters, Eli Zaretskii, 2016/01/25