From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables] Date: Tue, 6 Nov 2007 14:46:10 -0800 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1194389216 18976 80.91.229.12 (6 Nov 2007 22:46:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Nov 2007 22:46:56 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 06 23:46:59 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IpXCC-0002Wx-09 for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2007 23:46:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpXC1-0007Mb-1G for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2007 17:46:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IpXBw-0007MJ-F3 for emacs-devel@gnu.org; Tue, 06 Nov 2007 17:46:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpXBv-0007KH-6O for emacs-devel@gnu.org; Tue, 06 Nov 2007 17:46:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpXBv-0007K8-3V for emacs-devel@gnu.org; Tue, 06 Nov 2007 17:46:39 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IpXBu-0000Qb-I3 for emacs-devel@gnu.org; Tue, 06 Nov 2007 17:46:38 -0500 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id lA6MkZ2v014302 for ; Tue, 6 Nov 2007 15:46:35 -0700 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id lA6LAoQU004528 for ; Tue, 6 Nov 2007 15:46:35 -0700 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-81-9.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3348845721194389161; Tue, 06 Nov 2007 14:46:01 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:82684 Archived-At: > Since `set-variable' was also intended to change the values of user > options with the leading * in their docstrings, I think a new command > `set-option' should be added with the body of current `set-variable', > and `set-variable' should allow modifying any variable. > > I don't consider that a good reason for such a change. > If I see some additional experienced users who want this as a convenience, > then I will agree to the change. Those quotes provide some context, but this is really about `customize-set-value' and `customize-set-variable'. Here are some proposals for discussion: 1. Rename `customize-set-value' to `set-option', and `customize-set-variable' to `set-option-default' (or add aliases). Users will find these names easier. These commands provide much better interaction for reading the new value than does the current `set-variable'. Their interaction subsumes that of `set-variable', which uses only property `variable-interactive'. 2. Rewrite `set-variable' to set any variable, not just an option, and when the variable is an option then have the code do what `customize-set-value' does. That is, provide better value input interaction, when possible. 3. `customize-set-(value|variable)' needs some improvement. Here are some things I notice: a. `choice' for a list of `const' is good - it provides completion, which is very handy - a great improvement over what is available in Customize, IMO. However, there is no indication in the prompt that completion is (sometimes) available. And when completion is available, the default value should be the current value of the option, for possible editing. Currently, there is no default value. b. `choice' that includes a non-`const' choice, in addition to `const' choices: the types of the non-`const' choices apparently govern what happens: - If the non-`const' choice types don't provide for completion, then no completion is available for the `choice' at all. It would be better to have non-strict completion and allow for the value that doesn't match any `const' to be read according to its type. If possible. - And, if the non-`const' choices also provide for completion, then it should be possible to combine them with the `const' values into a general completion. E.g. a `choice' of a `function' or (const :tag "None" nil) currently completes only against function names - neither "None" nor nil are allowed as completion candidates. Why not just add "None" to the list of candidates? c. `repeat' seems to read a sexp and evaluate to obtain the complete list - the complete value. This is a cop-out and is not very useful. It would be better to repeatedly read values corresponding to the list elements, and then combine them to get the overall value. For example `repeat' of `sexp' should repeatedly read a sexp (until, say, empty RET) and return the list of sexprs that were read. And I don't see why the command should `eval' at all for `repeat' - why wouldn't it just read, like it does for the other types? And the user has no feedback as to what is expected to be input (beyond "[repeat]" in the prompt) - nothing tells him to input a sexp that will be evalled to produce the overall list value. (And end users should not need to think in such terms, anyway.) c. (choice (const :tag "None" nil) regexp) reads a regexp string, but the default is "", not nil, which doesn't seem right. And if you type `nil' or `None', then the literal string "nil" or "None" is interpreted as a regexp. Again, it would be better to allow lax completion with sole candidate "None" and allow a regexp string value as well. d. For type `color', lax completion should be available, choosing from color names but also allowing input of a #RRRGGBBB hex string. #3 is the most important of these suggestions. I don't have time to work on this much myself, but I can contribute a little time if someone else leads on this. What's really needed is someone knowledgeable in custom and widgets (ugh!). I hope that people will not argue that users should not use `customize-set-value' and `customize-set-variable', that they should preferably use Customize. I think both have their advantages, and these commands should be improved to make them viable alternatives. I also think that Customize itself could be improved to allow for completion where appropriate. WDOT?