From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrew Hyatt Newsgroups: gmane.emacs.devel Subject: Re: A proposal for removing obsolete packages Date: Sun, 24 Jan 2016 01:08:35 +0000 Message-ID: References: <83twmkkv16.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114323f818473f052a0a18a2 X-Trace: ger.gmane.org 1453597752 3426 80.91.229.3 (24 Jan 2016 01:09:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 01:09:12 +0000 (UTC) Cc: johnw@gnu.org, emacs-devel@gnu.org, Richard Stallman , monnier@iro.umontreal.ca To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 24 02:09:08 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aN9Ax-0000RO-GH for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 02:09:07 +0100 Original-Received: from localhost ([::1]:58925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN9Aw-0008BL-Ih for ged-emacs-devel@m.gmane.org; Sat, 23 Jan 2016 20:09:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN9Ai-0008Ay-E1 for emacs-devel@gnu.org; Sat, 23 Jan 2016 20:08:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aN9Ag-0004LG-RR for emacs-devel@gnu.org; Sat, 23 Jan 2016 20:08:52 -0500 Original-Received: from mail-vk0-x231.google.com ([2607:f8b0:400c:c05::231]:33176) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN9Ac-0004Ki-8u; Sat, 23 Jan 2016 20:08:46 -0500 Original-Received: by mail-vk0-x231.google.com with SMTP id e64so59225618vkg.0; Sat, 23 Jan 2016 17:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=mZw7iq61RXfpEWmhMhYA0ARiMJUzLZvEiVWcVbMP9gU=; b=hWNQWiyCA2ckVGZUMiimmVgCpwEAl4Vv1tWRbuLcv2aEGaowvXWHf2vO3RXEI6XAyb mOSzK1qBHv0rGuvXOCIt+1DYEvqB3U8Zp/31aLBbdkQ3cLfRiiy6irq2zJLD1vJ/i0Bp M6U+pgUakJSLfFnOf6Px8QQMsqt7ESUDzRdHnU0Pl+FlkRyWC7fBfcpbcS2mFCc6Lgmw mPgCbzpOh1ybBH7AsmqPOEiZlmilGyplyBWB7bEsonpCGp68IY6vVxkeJRq6dYYNWRQz gXGHsW3PPVpUaEFlZf2y4vjNBTuLTKwbPdk7XDs5yKR7fOq5NASlof6ivx8ldJZH77G1 bL/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=mZw7iq61RXfpEWmhMhYA0ARiMJUzLZvEiVWcVbMP9gU=; b=etZxYScu+8yLWTmX0gZBSFeF2WORodZ/KcTksH7E8HrFGerjuHpHCgh7H/FuvY/Ujz c7Vmw/qL0MuaaYZbCOcrWuWO7mJOSzJrsCyrxpEHC7+oyk0RBSgv04muqT9BNzY+rT/q qPHShlz6QnnCQ0WASGj1vhmNamfRa8Z6ZL+DKdrTZi8ofuAUGqn4QsgUzRi8UYBXOoTj N0IxvVKVnzSqvpVBxvfSM0lGZtfdgzqTBAKQcREej3D9piTWMpGQXUXBDxBBX8ve1JBO TojcEvwQ19SpR12uhSbWL8PfMlo/QdaH/ihUb+Dpc4NpKA3e/u2LYlDKASFqWe5edbmb SeSQ== X-Gm-Message-State: AG10YOQ3LH/HNGNc2/mD09n0KzoYgKqINQK6AFV7trzmv0vkagpet1/o+ummrlxBHjO4etCgrUAvJV2vlC4/yQ== X-Received: by 10.31.16.72 with SMTP id g69mr6689266vki.152.1453597725834; Sat, 23 Jan 2016 17:08:45 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198672 Archived-At: --001a114323f818473f052a0a18a2 Content-Type: text/plain; charset=UTF-8 On Sat, Jan 23, 2016 at 8:02 PM Andrew Hyatt wrote: > Drew Adams 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. > --001a114323f818473f052a0a18a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jan 23= , 2016 at 8:02 PM Andrew Hyatt <ahya= tt@gmail.com> wrote:
Drew Ad= ams <drew.ada= ms@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 th= eir
> current values and their documentation.
>
> That still seems useful to me.=C2=A0 If it is not, we should tell user= s
> what is its specific replacement.
>
> I see only this in the doc string of `list-options':
>
>=C2=A0 =C2=A0"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:=
>
>=C2=A0 =C2=A0"This facility is obsolete; we recommend using M-x cu= stomize instead."
>
> Really?=C2=A0 Just how do you "use Customize" to get a listi= ng such as
> `list-options' provides?=C2=A0 How do you use `M-x customize' = to get
> such a listing?
>
> I don't think you can get such a listing.=C2=A0 Certainly not with= just
> `M-x customize'.=C2=A0 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 Customiz= e
> then I think that command `list-options' (renamed, if necessary) > should be kept.=C2=A0 It could be moved to one of the `cus*.el' fi= les,
> if you really plan to toss `options.el'.

I hadn't used options before, but I tried now.=C2=A0 I guess I don'= t see the
usefulness of the command.=C2=A0 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).=C2=A0 But list-options instead gives = much,
much more than that in a buffer 38k lines long.=C2=A0 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 el= se that is customized outside of customize).=C2=A0 These should, hopefully,= solve your use-case.=C2=A0 Does it?
=C2=A0

>
>
> 2. Similarly, I think that command `edit-options' is still useful.=
>
> And yes, I'm familiar with Customize, and I use it often.=C2=A0 Bu= t I
> don't see that it replaces the specific behavior offered by
> `options.el'.=C2=A0 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.=C2=A0 It simply uses `set' to set the n= ew value.
> (This is true also of command `set-variable', BTW.)=C2=A0 To impro= ve 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.=C2=A0 Dunno.
>
> In any case, I've said it now - I don't see why this library n= eeds
> to be deprecated, much less removed.=C2=A0 It represents zero maintena= nce
> burden, unless I'm missing something.
>
> Sure, we want to encourage users to use Customize for most of their > user-option needs.=C2=A0 But I don't see the specific features off= ered
> by `options.el' being provided by Customize.=C2=A0 And I think the= y 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'.=C2=A0 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.=C2=A0 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.=C2=A0 I t= hink
> that such a view is missing with Customize.
--001a114323f818473f052a0a18a2--