From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Policy for backwards-incompatible changes? Date: Tue, 25 Oct 2011 12:08:04 +0800 Message-ID: <877h3tzpaz.fsf@gnu.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1319515703 1256 80.91.229.12 (25 Oct 2011 04:08:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2011 04:08:23 +0000 (UTC) Cc: joakim@verona.se, emacs-devel@gnu.org To: Dave Abrahams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 06:08:20 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 1RIYJH-0006f8-IM for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2011 06:08:19 +0200 Original-Received: from localhost ([::1]:55522 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIYJH-0005eJ-28 for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2011 00:08:19 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIYJD-0005e0-VC for emacs-devel@gnu.org; Tue, 25 Oct 2011 00:08:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIYJC-0000SN-KR for emacs-devel@gnu.org; Tue, 25 Oct 2011 00:08:15 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:40156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIYJC-0000SJ-Iv for emacs-devel@gnu.org; Tue, 25 Oct 2011 00:08:14 -0400 Original-Received: from bb116-14-207-132.singnet.com.sg ([116.14.207.132]:40428 helo=furball) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1RIYJA-00080V-Rh; Tue, 25 Oct 2011 00:08:13 -0400 In-Reply-To: (Dave Abrahams's message of "Sun, 23 Oct 2011 13:09:31 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:145494 Archived-At: 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. (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.