From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: `changed' theme. Date: Sat, 13 May 2006 21:46:44 -0500 (CDT) Message-ID: <200605140246.k4E2ki2d007475@jane.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1147574889 4314 80.91.229.2 (14 May 2006 02:48:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 14 May 2006 02:48:09 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 14 04:48:05 2006 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 1Ff6eK-0001mB-Kg for ged-emacs-devel@m.gmane.org; Sun, 14 May 2006 04:48:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ff6eK-0006nn-1H for ged-emacs-devel@m.gmane.org; Sat, 13 May 2006 22:48:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ff6e8-0006ng-Gk for emacs-devel@gnu.org; Sat, 13 May 2006 22:47:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ff6e7-0006nU-03 for emacs-devel@gnu.org; Sat, 13 May 2006 22:47:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ff6e6-0006nR-R9 for emacs-devel@gnu.org; Sat, 13 May 2006 22:47:50 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Ff6gC-0002WJ-Gu for emacs-devel@gnu.org; Sat, 13 May 2006 22:50:00 -0400 Original-Received: from jane.dms.auburn.edu (jane.dms.auburn.edu [131.204.53.201]) by manatee.dms.auburn.edu (8.13.6/8.13.6) with ESMTP id k4E2lnTc006509 for ; Sat, 13 May 2006 21:47:49 -0500 (CDT) Original-Received: from jane.dms.auburn.edu (localhost [127.0.0.1]) by jane.dms.auburn.edu (8.13.4+Sun/8.13.4) with ESMTP id k4E2kikA007478 for ; Sat, 13 May 2006 21:46:44 -0500 (CDT) Original-Received: (from teirllm@localhost) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3/Submit) id k4E2ki2d007475; Sat, 13 May 2006 21:46:44 -0500 (CDT) X-Authentication-Warning: jane.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: emacs-devel@gnu.org 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:54423 Archived-At: I know we discussed this before, but now things just seem too obvious. This `changed' theme makes no sense and it makes Custom unnecessarily complex. Even after Chong's latest change it still causes bugs, which I will report shortly. But the bugs are just one illustration of why it makes no sense. The basic problem is the following. Somebody sets an option outside Custom, or uses add-hook, in .emacs or during a session. Then he loads a theme. Or some Emacs feature, say a minor mode, sets an option or adds a function to a hook because it _needs_ to do so for correct functioning and then the user loads a theme that wants to set the option or hook. What should happen? If the user deliberately sat an option _through Custom_ and then loads a Theme containing tons of options, then the Theme does not override the explicit user customization. An explicit user setq or other non_Custom customization should not be overridden for exactly the same reasons. If an Emacs feature sat the value because it needed that value, the Theme should not override it and make the explicitly user enabled feature malfunction. The problem would be especially bad when users or Emacs features add functions to hooks or elements to listvars, which is perfectly legitimate for them to do. When the user then loads a theme, that theme could completely replace the value of the hook or listvar, thereby making Emacs features, or maybe even all of Emacs, malfunction, for instance by removing essential functions from hooks. Actually, themes should, in the current situation, _never_ try to set hooks, or listvars that have to be customized with add-to-list rather than setq. But they might easily try it anyway. I see no mention in the documentation that they should not do it. Preventing themes from overriding any user or program customizations (whether or not done through Custom) could at least prevent most of the worst problems (even though not all problems). _If_ Themes are going to override user/program "rogue" customizations, then at least they should not try to restore the old rogue value when the Theme gets unloaded. This can not be implemented in any remotely reliable way, because too much could have happened in the meantime. They should restore the "old" value as determined by Custom. The current implementation has bugs, that I will report separately. Sincerely, Luc.