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: Bug, probably related to Custom Themes. Date: Sun, 25 Dec 2005 11:38:39 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1135539559 3072 80.91.229.2 (25 Dec 2005 19:39:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 25 Dec 2005 19:39:19 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 25 20:39:18 2005 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Eqbi7-00081h-8w for ged-emacs-devel@m.gmane.org; Sun, 25 Dec 2005 20:39:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EqbjH-0004DP-Iq for ged-emacs-devel@m.gmane.org; Sun, 25 Dec 2005 14:40:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Eqbiz-0004AC-LJ for emacs-devel@gnu.org; Sun, 25 Dec 2005 14:40:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Eqbix-00047z-Uc for emacs-devel@gnu.org; Sun, 25 Dec 2005 14:40:09 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eqbix-00047t-Sg for emacs-devel@gnu.org; Sun, 25 Dec 2005 14:40:07 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Eqbie-0003jh-T7 for emacs-devel@gnu.org; Sun, 25 Dec 2005 14:39:49 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBPJcoel014401 for ; Sun, 25 Dec 2005 13:38:50 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBPJcnRk001646 for ; Sun, 25 Dec 2005 12:38:49 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw4-141-144-96-93.vpn.oracle.com [141.144.96.93]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBPJcmhd001630 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 25 Dec 2005 12:38:49 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:48360 Archived-At: Also everybody writing future code for Custom should realize that when they want to access the standard value, they should not just look at the 'standard-value property but that they should use the non-user theme value instead if there is one. Maybe we should add a subroutine which does this, to help people get it right every time. 1. Is there an acceptable alternative way to deal with this? I thought Luc was saying that there was, but I could be mistaken (I haven't followed everything in this thread). One consequence of fixing the problem by providing such a subroutine will be that code that tries to work with multiple versions of Emacs will become more complex that it would otherwise be (some versions will have the subroutine; others won't). I know that is not a priority concern of Emacs development, but you might want to consider it at some (secondary) level. "Users" of Emacs include not only its end users but also external-library developers, and the latter sometimes try to provide code that works across different Emacs versions, FBOFW. 2. Luc also seemed to be saying that there is unnecessary coupling now between the themes code and the custom code, making writing code that uses either of them trickier or more complex. If the two are as incestuously intertwined as Luc suggests, wouldn't it make sense to cut some of the bonds and have them shake hands at a more respectable distance? I don't know if that would be possible before the release, but the impression I get from Luc's description is that maintenance and bug storms are looming in this area. I'm all for letting other libraries change custom values and states, as I've stated previously. Custom is so important and potentially useful, that we shouldn't confine its functionality to the Customize UI. But if other libraries break Customize functionality, then that's not good. And if people must be aware of multiple libraries and their effects in order to interact with Customize (interactively or through code), then that's not good either. My idea was to let other libraries use Customize functionality, but that must be done cleanly and transparently - as if it were done by/in Customize itself.