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: Thu, 21 Oct 2010 21:34:32 -0700 Message-ID: <823F3463F14A490A90A6075368296AC2@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> 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 1287722176 5872 80.91.229.12 (22 Oct 2010 04:36:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 22 Oct 2010 04:36:16 +0000 (UTC) Cc: 'Emacs-Devel devel' , 'Miles Bader' To: "'Stephen J. Turnbull'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 22 06:36:14 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 1P99MR-0002IF-M2 for ged-emacs-devel@m.gmane.org; Fri, 22 Oct 2010 06:36:12 +0200 Original-Received: from localhost ([127.0.0.1]:42501 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P99MQ-0000FE-W1 for ged-emacs-devel@m.gmane.org; Fri, 22 Oct 2010 00:36:11 -0400 Original-Received: from [140.186.70.92] (port=37534 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P99MJ-0000F9-3J for emacs-devel@gnu.org; Fri, 22 Oct 2010 00:36:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P99MH-0006H7-Pf for emacs-devel@gnu.org; Fri, 22 Oct 2010 00:36:02 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:43968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P99MF-0006GO-RU; Fri, 22 Oct 2010 00:36:00 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9M4Ztpk023655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 04:35:57 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9M0xXo9002781; Fri, 22 Oct 2010 04:35:55 GMT Original-Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 705859801287722072; Thu, 21 Oct 2010 21:34:32 -0700 Original-Received: from dradamslap1 (/10.159.232.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Oct 2010 21:34:32 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87bp6nklx2.fsf@uwakimon.sk.tsukuba.ac.jp> Thread-Index: Actxj4ZwvaMz9CjSS+OYg4c35XRyPwAAF4DQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 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:131968 Archived-At: > > However, I disagree that [set-variable] is not that much more > > convenient than setq. For one thing, it respects the defcustom > > :type spec. For another, it uses a proper interactive spec. The > > type-checking in particular is a win, IMO. > > I don't find either of those noticable. 1. Type-checking is noticeable in that you cannot enter a value whose type conflicts with the defcustom type. With `setq' you can. (The type mismatch error message should be more helpful, however, instead of just saying "Value `VAL' does not match type choice of OPTION".) But I'm not trying to convince anyone to use `set-variable'. It's fine if you don't find it useful. 2. The interactive reading of a value by `set-variable' depends on the variable having a `variable-interactive' property. I use that property in my own code, but vanilla Emacs does not anymore. (There are exactly 3 variables left in all of the vanilla Lisp sources that have this property: `tags-file-name', `sgml-transformation-function', and `skeleton-transformation-function'.) So I'm not surprised that you don't find it noticeable. ;-) Try, for instance, `M-x set-variable tags-file-name' and compare the behavior with that of `M-x set-variable custom-file'. The former gives you file-name completion. The latter gives you nada. That's a noticeable difference. So yes, I would also BTW suggest that we use property `variable-interactive' more. Or better yet make Customize automatically DTRT, at least in the simple cases (e.g. automatically set that property, or provide the behavior in some other way), so that `set-variable' is helpful with the values of most user options (not just 3!). Even many defcustom `choice' types could be made accessible using completion. Obviously `const' choices could, and even a type like `function' could, allowing completion against known function names. (The completion would be non-strict, letting you enter a lambda form etc.) `set-variable' could at least be made to offer the degree of interactive help (e.g. completion) that is provided for value-editing in Customize. I never understood why this feature was abandoned. The doc (`(elisp) Defining Variables') says: "If a user option variable has a `variable-interactive' property, the `set-variable' command uses that value to control reading the new value for the variable. The property's value is used as if it were specified in `interactive' (*note Using Interactive::). However, this feature is largely obsoleted by `defcustom' (*note Customization::)." That last part is a bit presumptuous, IMHO. Perhaps it means to say only that `set-variable' is largely obsolete (although I don't see why it would be - it is quick; Customize is not). ("Obsolete" is not a verb BTW (e.g. "obsoleted"), although it is true that you can verb any noun.) But it seems to also be suggesting that Customize replaces `set-variable's reading of a value according to an `interactive' spec, which it does not. Customize sometimes lets you use completion when editing an option value, granted. But if you have to enter the jungle of Customize and survive to come out the other side in order to get the benefit of an `interactive' spec (editing the value) then I'd say that some of that benefit has been lost. Just an opinion. One person's loss is another person's obsolete. ;-) (Tomorrow morning some earnest soul will no doubt remove those 3 vestigial `variable-interactive' properties in a cleanup sweep to purge the code once and for all...) > > (FWIW, I use it often.) > > I'm curious, what are your use cases? As I said before, more or less the same use cases as using Customize to set a value (without saving it): `M-x customize-option' Edit value or choose value using menu. Click `Set for this session'. `q' When might one use Customize instead of setq? I do it when I want to test things that involve various option menu values, or when the option value is somewhat complex. Sometimes I'll keep a particular Customize buffer open in a separate frame and make various value changes while testing things. And setting a value using Customize instead of setq can help when I don't recall the exact structure of the value (the custom :type). `set-variable' is quicker for this than Customize. It offers some of what Customize offers but is as quick as setq. However, it helps with the value reading only if propery `variable-interactive' is set. And again, it would help more with the type if the mismatch error were more informative. Let me be clear: by "often" I don't mean that I use `set-variable' every 3 minutes. But I do use it fairly often instead of entering Customize or using setq. I also use other, non-vanilla commands to increment a numerical option, toggle any binary option (not just custom-type `boolean'), and so on. I use this kind of thing more than some people perhaps because I use Emacs to develop and test Emacs-Lisp code more than I use Emacs for other things. (The only thing Emacs is good for is Emacs...but that's a lot.) Also, I don't necessarily treat user options as things to be set once in a blue moon and persist. I don't mind commands that change option values, even incrementally/dynamically. Even if an option were never persisted its typing would still be a useful feature. I take advantage of both the typing and the persistence of Emacs options without always treating them as statically as others do. I even proposed that Emacs allow for (i.e., optionally) typing non-option vars. That suggestion was summarily dismissed by you - the sole responder, with the single word "YAGNI". http://lists.gnu.org/archive/html/emacs-devel/2009-10/msg00668.html We have different views of Emacs and its features. That's OK. YAGNI. But IUI.