From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dave Abrahams Newsgroups: gmane.emacs.devel Subject: Re: Policy for backwards-incompatible changes? Date: Mon, 31 Oct 2011 11:13:21 -0800 Message-ID: References: <877h3tzpaz.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1320089792 15571 80.91.229.12 (31 Oct 2011 19:36:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 Oct 2011 19:36:32 +0000 (UTC) Cc: joakim@verona.se, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 31 20:36:26 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RKxef-0004rA-6T for ged-emacs-devel@m.gmane.org; Mon, 31 Oct 2011 20:36:21 +0100 Original-Received: from localhost ([::1]:50754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKxee-0002AI-8u for ged-emacs-devel@m.gmane.org; Mon, 31 Oct 2011 15:36:20 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKxeb-0002AD-C1 for emacs-devel@gnu.org; Mon, 31 Oct 2011 15:36:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKxea-0007pM-AQ for emacs-devel@gnu.org; Mon, 31 Oct 2011 15:36:17 -0400 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:58898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKxeY-0007oz-TQ; Mon, 31 Oct 2011 15:36:14 -0400 Original-Received: by vcbfl17 with SMTP id fl17so571561vcb.0 for ; Mon, 31 Oct 2011 12:36:14 -0700 (PDT) Original-Received: by 10.220.156.8 with SMTP id u8mr2594048vcw.10.1320089774388; Mon, 31 Oct 2011 12:36:14 -0700 (PDT) Original-Received: from pluto.local (129-134-58-66.gci.net. [66.58.134.129]) by mx.google.com with ESMTPS id cp16sm11248567vdb.20.2011.10.31.12.36.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 12:36:13 -0700 (PDT) Original-Received: by pluto.local (Postfix, from userid 501) id 9504C123716A; Mon, 31 Oct 2011 11:13:21 -0800 (AKDT) In-Reply-To: <877h3tzpaz.fsf@gnu.org> (Chong Yidong's message of "Tue, 25 Oct 2011 12:08:04 +0800") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.220.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145819 Archived-At: on Mon Oct 24 2011, Chong Yidong wrote: > Dave Abrahams writes: > >> This, and the fact that I've received no other answers, support my >> suspicion that the design of themes may not be working well for the >> user community. As far as I can tell, the only thing required to make >> themes work as you and I would want them to would be to give the >> "user" (i.e. default) theme lowest priority rather than highest. >> >> But this is a fairly radical change to make silently. What would need >> to happen before something like that could be done? > > One would have to fix the Customize interface, which currently assumes > that the user theme takes precedence over themed variables (e.g. it > marks themed but not customized variables as THEMED). > > If that is fixed, I think the way to handle the theme and Customize > interaction is to add the `user' theme to the custom-enabled-themes > variable, so that it is treated on a similar footing to themes---the > user can explicitly specify their relative priorities. So it would be automatically inserted at the front of the list if it wasn't already there, as a way to preserve backward compatibility. I like it! However, we would still be breaking backward compatibility in that enabling a theme with a setting already in the "user" theme would now override that setting. If that doesn't bother anyone, I'm happy with it. > (The `custom-enabled-themes' variable itself would have to be treated > specially, of course, but that's also the case currently; you can set > it from a theme.) > > The commands like `load-theme', if called interactively, could prompt > for whether or not to override the `user' theme. So it sounds like you would be open to accepting a patch that would implement this? -- Dave Abrahams BoostPro Computing http://www.boostpro.com