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: Sat, 23 Jan 2016 20:02:09 -0500 Message-ID: References: <83twmkkv16.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1453597356 30787 80.91.229.3 (24 Jan 2016 01:02:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 01:02:36 +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:02:35 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 1aN94d-0005aD-0w for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 02:02:35 +0100 Original-Received: from localhost ([::1]:58919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN94Z-0006qA-7z for ged-emacs-devel@m.gmane.org; Sat, 23 Jan 2016 20:02:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN94M-0006q0-42 for emacs-devel@gnu.org; Sat, 23 Jan 2016 20:02:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aN94I-00030R-3F for emacs-devel@gnu.org; Sat, 23 Jan 2016 20:02:18 -0500 Original-Received: from mail-qk0-x230.google.com ([2607:f8b0:400d:c09::230]:34847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aN94H-00030N-UG; Sat, 23 Jan 2016 20:02:14 -0500 Original-Received: by mail-qk0-x230.google.com with SMTP id o6so42819310qkc.2; Sat, 23 Jan 2016 17:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=QtTLwGi5E7fN+yY6LSCkcBGrPvxaO+lbhnCscK7b6oc=; b=k/5e83UnkbqecQHJvqYERCOrvhTLyR3MQm21Wzlczou54GKC0cs06zwfzgdIrmsNzl 2nx5FTbcQDLr6Q7M4n8lwTLlCuOj2vzrZulMxQ+YUeHMVXrlqHsJo5LUmVO7laBLYVN5 XTsZrSr6PCi+lZA/U7gj6ZcsNbODRK/SSGciegkx2T639kvY4U0WnwGeK3f/5aIjbC6b R6IeZAv0Sdsp9ZZWx1zVmiRF4IYAeSmawUhJNVxH+7/ON11rQd7+o9fb6G4goZn4NHeU ON3EpKfgfYZHilFOp/nrmgSV1Y9+xtwvMbVAW0PqY+jR8L5/to6wj88YjWenGsodPz1s 5bCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=QtTLwGi5E7fN+yY6LSCkcBGrPvxaO+lbhnCscK7b6oc=; b=j2AwjTLc9Jtt5gcs/MgBn8dpGdkDr3C5q8+LEf59pIFbxGdXd4821YiReXIKCELmit im6gbyJ1IR1C9FkQAmNghq8Q3i8RWJR8RNX/hYE2Em9h2Y5XOp6WB6XDn4YngXSagydz S4BPBoqNTXyiTfbuSxiO+veWkEXqWxqX5g1lLAzr9rKegcUOVC6BJ2vFjeoW3/LQ7ZW0 cAbgrhUEWc6jSKzHVWbHGG6NjLcGtErGdrhw0XNTHUZyT8NUsUROL7nBBiayFCA/54Sc +V3pLTD6BUmQr/GXrGfaicj35lHdGWLKJVZ+R3YGaZ/BYoykkv4PNkdCSuNvbYusS2zG 22DQ== X-Gm-Message-State: AG10YOQdFptE0aDB0pzUrN+bceZQ7TXsdc0JHjC1HFqWXmhUPOrW2Cl9LHchVfuL5OvEcQ== X-Received: by 10.55.73.68 with SMTP id w65mr12771985qka.68.1453597333419; Sat, 23 Jan 2016 17:02:13 -0800 (PST) Original-Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id a197sm5911308qhc.25.2016.01.23.17.02.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jan 2016 17:02:11 -0800 (PST) In-Reply-To: (Drew Adams's message of "Sat, 23 Jan 2016 14:03:36 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::230 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:198671 Archived-At: 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? > > > 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.