From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: In defense of Customize [was: Trying to right-align my window on startup] Date: Thu, 16 Jan 2014 07:33:46 -0800 (PST) Message-ID: <042f4c2c-d110-480f-aaa5-2a317855e189@default> References: <3cec217d-8adb-4e6c-b239-eff0c8b520c9@googlegroups.com> <5581e666-3500-4a30-abb2-6454e2398a01@default> <87txd57d2b.fsf@newcastle.ac.uk> <8a68f95d-4916-4a5d-a92c-b5de5f8f4d6e@default> <87lhyg5jgy.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389886462 14830 80.91.229.3 (16 Jan 2014 15:34:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 15:34:22 +0000 (UTC) Cc: Rusi , help-gnu-emacs@gnu.org To: phillip.lord@newcastle.ac.uk Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jan 16 16:34:26 2014 Return-path: Envelope-to: geh-help-gnu-emacs@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 1W3oxa-00008W-9w for geh-help-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 16:34:22 +0100 Original-Received: from localhost ([::1]:33373 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3oxZ-0008O1-Q9 for geh-help-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 10:34:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3oxE-0008Ng-OW for help-gnu-emacs@gnu.org; Thu, 16 Jan 2014 10:34:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3ox6-0008Mb-5q for help-gnu-emacs@gnu.org; Thu, 16 Jan 2014 10:34:00 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:40636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3ox5-0008MG-Vb for help-gnu-emacs@gnu.org; Thu, 16 Jan 2014 10:33:52 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0GFXmV0017591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jan 2014 15:33:49 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0GFXlPl022722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jan 2014 15:33:48 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s0GFXlSo004714; Thu, 16 Jan 2014 15:33:47 GMT In-Reply-To: <87lhyg5jgy.fsf@newcastle.ac.uk> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:95440 Archived-At: > >> I would like to have a "custom-setq" which set a var, checked to see > >> whether the types were correct wrt customize, then crashed if not. It > >> would be nice to use the knowledge of customize from lisp. > > > > See commands `customize-set-variable' and `customize-set-value'. >=20 > These don't do quite what I want. See below - you might change your mind about that. > As a random example, It would be better to choose an example from the distributed vanilla Emacs code. Emacs Dev is more likely (but far from guaranteed) to use :type wisely and write accurate doc strings than is a random 3rd-party library developer. > consider this: > (defcustom pulse-flag (pulse-available-p) > "... > If the value is nil, ... > If the value is `never', ... > Any other value means ...." > :group 'pulse :type 'boolean) OK, the doc does not match the :type spec. So let's see what the story is. There are a couple of possibilities. 1. It could be that the intention was that the value really must be as the doc describes it, and any other value should raise an error. In which case, code that uses the option can and even perhaps should depend on that. In that case, the :type is incorrect. Perhaps the programmer was lazy wrt specifying :type. See my earlier post about that - users of defcustom should get to know :type and do their best to use it to advantage. 2. It could be that the :type spec is correct and the doc string is inaccurate. Seems unlikely in this case, but could be checked by looking at how it is used in the library that defines it. It is checked only by `eq'uality with symbol `never' and with nil. One might conclude that the programmer in this case was lazy or ignorant wrt :type, or just didn't care. It's also possible, however, that this was the intention: a disconnect between the actual possible values and the values users can set using Customize. A programmer *can* intend such a disconnect (though in that case it might be appropriate to document that, either in the program doc or code comments). The code itself never sets a value of `never', so it seems unlikely that this is intended as an internal value (especially since it is advertised in the doc string). Rather, it is likely intended as a value that users can use. Is it intentional that users *cannot* set the value to `never' using Customize? Dunno. My guess in this case would be that this is yet another case of a programmer being lazy or not sufficiently :type-savvy. That is all too common - in part perhaps because some tend to give Customize a back seat, thinking it is only for wimps. (Akin to a certain lack of respect for users, in my book.) My guess is that what was meant was something like this: :type '(choice (const :tag "Do not color" never) (const :tag "Color without pulsing" nil) (sexp :tag "Color with pulsing" t)) That lets both `M-x customize-option' and `customize-set-variable' DTRT. They both let you choose one of the same three "values" - the :tags, actually. `customize-set-variable' lets you use completion to do that. If you choose `Color with pulsing' then you are prompted for a sexp that will be the value. But hey! That's still not good enough. No doubt the sexp here should not be either `nil' or `never'. To guard against that, the :type should use `restricted-sexp' with an appropriate predicate, instead of just `sexp'. You can see that things can get complicated if the logic and use of an optin is complicated. Whether that kind of treatment is really needed here, or whether the last `choice' possibility could (and should) be just (const :tag "Color with pulsing" t), would depend on what the intention is, and thus what the code does with it. > In this case, the ability to set an "illegal" value is actually > useful, because the :type is wrong,=20 Yes. (Or so it seems - something is wrong, at least.) > as legal values are t, nil or 'never (according to the > documentation) not just 'boolean. Yes. > Why has this never been discovered? I would suggest two > possibilities: a) the developers have never, ever set > 'pulse-flag or b) they just used setq in their .emacs. See above. Even if they use only setq, the code and doc do not match. The likely answer in this case (based on a quick check of how the variable is used) is that the developers were either lazy wrt :type or ignorant wrt :type or did not really care. > If the latter is true, having a way of only setting legal > values according to customize would have been helpful, > because this would have crashed, and they would have fixed it. See above.