From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: wgreenhouse@riseup.net (W. Greenhouse) Newsgroups: gmane.emacs.bugs Subject: bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration Date: Tue, 26 Nov 2013 19:44:48 +0000 Message-ID: <8761rf9ccv.fsf@motoko.kusanagi> References: <87d2ln9f0b.fsf@motoko.kusanagi> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385495177 24832 80.91.229.3 (26 Nov 2013 19:46:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Nov 2013 19:46:17 +0000 (UTC) Cc: wgg2@member.fsf.org, 15687@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 26 20:46:19 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VlOaO-0006Tf-SH for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Nov 2013 20:46:17 +0100 Original-Received: from localhost ([::1]:60674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlOaO-0002K3-Gv for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Nov 2013 14:46:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlOaF-0002Gz-BK for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2013 14:46:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlOaA-0005Hr-Hk for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2013 14:46:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlOaA-0005Hn-E5 for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2013 14:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VlOa9-00070e-UA for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2013 14:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: wgreenhouse@riseup.net (W. Greenhouse) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Nov 2013 19:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15687 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-Cc: "William G. Gardella" , bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.138549512326893 (code B ref -1); Tue, 26 Nov 2013 19:46:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 26 Nov 2013 19:45:23 +0000 Original-Received: from localhost ([127.0.0.1]:46385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VlOZW-0006zg-Cz for submit@debbugs.gnu.org; Tue, 26 Nov 2013 14:45:22 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33072) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VlOZU-0006zT-Go for submit@debbugs.gnu.org; Tue, 26 Nov 2013 14:45:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlOZK-00058E-9g for submit@debbugs.gnu.org; Tue, 26 Nov 2013 14:45:15 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:47119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlOZK-00058A-7Q for submit@debbugs.gnu.org; Tue, 26 Nov 2013 14:45:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlOZF-0001pk-Of for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2013 14:45:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlOZB-0004rB-9O for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2013 14:45:05 -0500 Original-Received: from mx1.riseup.net ([198.252.153.129]:38416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlOZB-0004qx-0v for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2013 14:45:01 -0500 Original-Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 8821D4B17B; Tue, 26 Nov 2013 11:44:57 -0800 (PST) Original-Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: wgreenhouse@fulvetta.riseup.net) with ESMTPSA id EE35C180 In-Reply-To: (Drew Adams's message of "Tue, 26 Nov 2013 11:01:53 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Virus-Scanned: clamav-milter 0.97.8 at mx1 X-Virus-Status: Clean X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:81008 Archived-At: Drew Adams writes: > Please read the bug report. It includes the case where all themes > that have ever been applied have since been disabled. That does not > restore all other customizations that were in effect before theming. > That's all. I read the bug report in detail. Despite its length, it failed to provide a minimal recipe for reproducing the bug. Without it, I essentially had to read your mind. What I have been able to discover on my own is that Custom themes do not prevent you from easily and completely restoring faces altered with M-x customize. I was able to do so in my example. > If you need a recipe, emacs -Q, load oneonone.el, then doremi.el and > doremi-cmd.el. Then cycle among themes, using `doremi-custom-themes+'. > Use `C-g' to cancel. The initial state is not restored. Nothing > close to it. Not for any existing frames. Since I was able to revert in the same frame completely without these libraries, I think the problem lies not in the implementation of Custom themes but rather the implementation for changing them in these libraries. To achieve a clean slate, `doremi-custom-themes' should do exactly what `customize-themes' does: if `custom-theme-allow-multiple-selections' is nil, `disable-theme' should be called for every element in `custom-enabled-themes' before enabling a new one. > Sure, if you then create a new frame, things will look generally OK > in that frame. But the state of any existing frames has been altered > and not restored. Disabling a theme does not undo its effect wrt > Emacs in general. It simply disables one theme wrt other themes > (including wrt all other themes). Disabling a theme undoes its effect with respect to any setting made through M-x customize. > In addition, I see no way to take a snapshot of the current Emacs > state as a theme, or even as a pseudo theme, to which one can revert. (customize-create-theme) is roughly equivalent to `color-theme-make-snapshot'. It fills out a Custom theme using Emacs's current state as a basis. > This is something that is trivial with color themes - just call > `color-theme-make-snapshot'. > > Try the same thing, but with command `doremi-color-themes+'. > No problem. As I alluded to in the last post, I think the problem lies in UI and user expectations rather than underlying implementation. I was never able to get color-theme.el themes to undo themselves cleanly, because I hadn't discovered `color-theme-make-snapshot' or your functions taking advantage of it. As far as I can determine from testing from emacs -Q, Custom themes adhere to what (info "(emacs) Custom Themes") says they adhere to: > Any customizations that you make through the customization buffer > take precedence over theme settings. This lets you easily override > individual theme settings that you disagree with. If settings from two > different themes overlap, the theme occurring earlier in > `custom-enabled-themes' takes precedence. In the customization buffer, > if a setting has been changed from its default by a Custom theme, its > `State' display shows `THEMED' instead of `STANDARD'. Stuff set through Customize (whether before or after loading Custom themes) survives enabling a theme, and those customizations will still be there when any/all themes are disabled. And in my own setup, which is fairly complicated (an Emacs that's also subject to ~/.Xresources theming as well as theming by elisp), frames do "return to normal" when all themes are disabled. I don't think Custom themes guarantee anything for settings made otherwise than through M-x customize; for that case you could use (customize-create-theme) similarly to how you'd use (color-theme-make-snapshot) to make a point to reverse to. -- Best, WGG