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: Shouldn't custom.el load wid-edit.el? Date: Fri, 28 Dec 2007 07:39:56 -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 1198856583 26058 80.91.229.12 (28 Dec 2007 15:43:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Dec 2007 15:43:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 28 16:43:16 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 1J8HMe-0002hh-3n for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2007 16:43:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8HMI-00058Q-VJ for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2007 10:42:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8HKo-0003WN-H2 for emacs-devel@gnu.org; Fri, 28 Dec 2007 10:41:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8HKl-0003SI-6r for emacs-devel@gnu.org; Fri, 28 Dec 2007 10:41:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8HKl-0003S6-0Z for emacs-devel@gnu.org; Fri, 28 Dec 2007 10:41:15 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J8HKh-0001ql-6N; Fri, 28 Dec 2007 10:41:11 -0500 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lBSFexfM031886; Fri, 28 Dec 2007 09:40:59 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id lBSFOloA028528; Fri, 28 Dec 2007 08:40:58 -0700 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-81-155.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3467634311198856394; Fri, 28 Dec 2007 07:39:54 -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:85550 Archived-At: > But it means that `defcustom' does not recognize those > built-in Emacs types that wid-edit.el defines. > > What do you mean, "recognize"? In what sense does `defcustom' need to > "recognize" a type? All it does is record the type to be used if and > when you try to DO something with the variable later. That is when > we want wid-edit.el to be loaded. What type does it record? See the example I gave (repeated below). defcustom _evaluates_ the :type sexp you give it. That means the defcustom needs to recognize the set of basic types at that time, in order to eval that sexp. (It's not unlikely that the sexp for a :type involves existing types.) Here again is the example: > I did this, to let some code work also in older Emacs versions > that don't define type `color': > > (defcustom... :type (if (get 'color 'widget-type) > 'color > 'string) > ...) > > I was surprised to find that in Emacs 22 also the type was `string'. > > The problem was that the widget `color' is defined in > wid-edit.el, which was not loaded. So I now do this, which > seems a bit heavy-handed for user code: > > (defcustom... :type (if (and (require 'wid-edit nil t) > (get 'color 'widget-type)) > 'color > 'string) > ...) IOW, it is currently up to the user to teach defcustom what its own basic :type's are (that is, what the Emacs basic types are) so that it can eval the :type sexp. Shouldn't it be the other way around - shouldn't defcustom be helping the user in this regard? I think the problem is this: types in Emacs, and the type-checking code, are currently packaged up with the Widget UI and the Customize UI code. You are right that code that deals with creating and managing widgets as UI thingies should not need to be loaded until we actually need to create and use those UI thingies. The problem is that we should be able to use types and check them, regardless of whether (that is, before) we make use of such a UI. IOW, I agree with the logical separation you mention wrt load time, but, to do that and also still make types available normally, the code would need to be refactored. Unless someone is up to that task, we should just load wid-edit.el for defcustom to be able to interpret :type sexps with knowledge of Emacs types. Currently, defcustom is not dealing with a full deck.