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: RE: `set-variable' should use :set Date: Fri, 22 Oct 2010 09:03:30 -0700 Message-ID: <9D3797AD2E4848CB8459CA74A2218F63@us.oracle.com> References: <87d3r3qd44.fsf@catnip.gol.com> <871v7jqchc.fsf@catnip.gol.com><033D7FA139144B03B1370B9E9C1113ED@us.oracle.com><87bp6nklx2.fsf@uwakimon.sk.tsukuba.ac.jp><823F3463F14A490A90A6075368296AC2@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1287763526 22559 80.91.229.12 (22 Oct 2010 16:05:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 22 Oct 2010 16:05:26 +0000 (UTC) Cc: "'Stephen J. Turnbull'" , 'Miles Bader' , 'Emacs-Devel devel' To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 22 18:05:24 2010 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.69) (envelope-from ) id 1P9K7O-00031B-Rx for ged-emacs-devel@m.gmane.org; Fri, 22 Oct 2010 18:05:24 +0200 Original-Received: from localhost ([127.0.0.1]:34355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9K7M-0000Eh-MF for ged-emacs-devel@m.gmane.org; Fri, 22 Oct 2010 12:05:20 -0400 Original-Received: from [140.186.70.92] (port=60674 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9K5o-0007qs-KT for emacs-devel@gnu.org; Fri, 22 Oct 2010 12:03:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P9K5n-0006ny-99 for emacs-devel@gnu.org; Fri, 22 Oct 2010 12:03:44 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:43417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P9K5l-0006mq-Cz; Fri, 22 Oct 2010 12:03:41 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9MG3ZUt008785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 16:03:37 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9M6lEBI017582; Fri, 22 Oct 2010 16:03:32 GMT Original-Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 707707721287763412; Fri, 22 Oct 2010 09:03:32 -0700 Original-Received: from dradamslap1 (/10.159.219.235) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 Oct 2010 09:03:31 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Actx8a8p+DS67GMtQ5StjVR9ugTlsgAAnpVQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-reply-to: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:131994 Archived-At: > I think Drew wants set-variable and customize-set-variable > to be made more similar. I would agree and I think we should > merge them. I would also suggest that it's a good opportunity > to obsolete variable-interactive. Yes, that all sounds good to me. But the last part would hopefully entail automatically getting the equivalent of `variable-interactive' from the custom type (e.g. along the lines I suggested). And hopefully the type-checking would give you a better error message than the generic "Value does not match number type". And there is potential synergy between those two. If, for example the :type is: (alist :key-type (string :tag "Sort order") :value-type (choice :tag "Type" (const :tag "None (do not sort)" nil) (function :tag "Sorting predicate") (list :tag "Sorting multi-predicate" (repeat (function :tag "Component pred")) (choice :tag "Final predicate?" (const :tag "None" nil) (function :tag "Predicate"))))) Then the interactive spec could allow completion or other appropriate input methods (e.g. reading a number) for each of the parts in turn, type-checking it individually. If tags are present they could be used in the prompts. Example: 1. "Sort order: " no completion (string) 2. "Type: " completion with candidates: `None (do not sort)' `Sorting predicate' `Sorting multi-predicate' 3. Supposing `Sorting multi-predicate' was chosen: "Component pred: " lax completion on fboundp symbols "Component pred: " ... until empty input (for example) 4. "Final predicate? " completion with candidates: `None', `Predicate' 5. Supposing `Predicate' was chosen: "Predicate: " lax completion on fboundp symbols If a tag is not provided, then the immediate type name would be used in its place - e.g. "function: " if there were no tag "Sorting predicate". This could go a long way toward helping, including dealing with typing mistakes (in both senses of the word). Currently, you're on your own coming up with a proper Lisp sexp that fits the custom type - e.g. (("My Sort 1" (info-cp gnus-cp file-cp) alpha-p)). Currently the prompt just punts: "[alist] Set customized value for ___ to: ". Yes, use of such a `(customize-)set-variable' command would obviously be better for simple custom types than for complex ones like this. If the type is quite complex then it can be easier/clearer to enter Customize and deal with it there. The example is meant to show that _even_ complex types could be handled in a relatively straightforward way. Users might well prefer to enter Customize for such a type rather than answer a series of voice-mail-hell-like prompts. But for simpler types avoiding Customize would be a worthwhile. Essentially, the idea is that `(customize-)set-variable' would offer a (helpful) minibuffer UI as an alternative to entering Customize in order change an option value. The point is that we could do better than just prompt for a complete "[alist] " value in one shot. We could offer a reasonable way to input each of the value components, providing completion as appropriate. Each part would be type-checked on its own, letting users know just where they go wrong when inputting. And for times when you really want to input a fancy sexp and you prefer using such a command to using setq (so you get type-checking), we could let `C-u' give you the all-or-nothing "[alist] " prompt offered today.