From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: byte compiling defcustom Date: Sun, 18 Nov 2007 15:29:25 -0800 Message-ID: References: <200711171647.lAHGlHqH024027@jane.dms.auburn.edu> <200711172032.lAHKWhgx025030@jane.dms.auburn.edu> <200711172041.lAHKf2SG025058@jane.dms.auburn.edu> <200711180413.lAI4DLF8025958@jane.dms.auburn.edu> <200711181841.lAIIfDB2028254@jane.dms.auburn.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1195428748 15793 80.91.229.12 (18 Nov 2007 23:32:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Nov 2007 23:32:28 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org To: Luc Teirlinck Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 19 00:32:34 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 1Ittcv-0007Mo-JC for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2007 00:32:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ittci-0000Cx-4v for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2007 18:32:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ittce-0000C1-B2 for emacs-devel@gnu.org; Sun, 18 Nov 2007 18:32:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ittcb-0000BJ-Ah for emacs-devel@gnu.org; Sun, 18 Nov 2007 18:32:15 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ittcb-0000BE-4T for emacs-devel@gnu.org; Sun, 18 Nov 2007 18:32:13 -0500 Original-Received: from oogie-boogie.ics.uci.edu ([128.195.1.41]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IttcW-0005hP-PK; Sun, 18 Nov 2007 18:32:09 -0500 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id lAINTPIl007257; Sun, 18 Nov 2007 15:29:27 -0800 (PST) Original-Lines: 62 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Solaris 9 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:83592 Archived-At: Luc Teirlinck writes: > Richard already made a decision on this. But just to help you explain > the decision: IMVHO Richard made a decision based on incomplete data. It might be too late now, but I wanted to state my position. Again, I claim that if the user needs to see lisp for a defcustom, then the defcustom is not designed well enough and is not very user friendly. To me it seems that maintaining an infrastructure to access the original lisp values for defcustom is just added complexity with no real benefit to users, and with _very_ limited benefit for one or two hackers that even know about this. Defcustom now effectively hides the definition from the byte compiler, and the byte compiler warnings are the easiest way to find some bugs. But I admit, I might be wrong about this, so a simple counter example should be convincing enough. > This returns (2). And I would argue that this is the right thing to do > for _this_ example > > For _this_ example obviously yes, but see my response to Stefan. I saw it, but I failed to see anything compelling there. > Now, is there a situation where showing a lisp expression is the desired > thing? Any examples in the emacs sources? > > Plenty, but since a decision has already been made, I am not going to > spend time finding some of them among the even more numerous > defcustoms whose default values are booleans and such (for which it > does not make a difference). Please give a single example, just claiming that it does exist not show that it is indeed true. > Without any examples I am inclined to believe that showing users lisp > code defeats one of the purposes of defcustom: not having to write lisp > to customize behavior. > > It does not _serve_, but in no way _defeats_ either, _one_ of the > purposes of Custom. (The Lisp only gets shown if the user _asks_ for > it). But it serves several _other_ purposes of Custom, such as: use > as a convenient browser with possibility to conveniently edit the > standard value without having to grep through the source code, visit > .emacs, cut and paste and so on. True, but how is this relevant to the problem at hand? > Also, the possibility to conveniently manage the new value > afterwards. In addition, it is a help to people who want to > gradually transition from just using straightforward customizations > to writing Lisp. Again, an example would be more useful than just stating this.