From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Face color changes Date: Wed, 29 Dec 2004 20:27:47 -0500 Message-ID: <20041230012747.GA29490@fencepost> References: <01c4ec3a$Blat.v2.2.2$24b7cc60@zahav.net.il> <87oegf5974.fsf@jurta.org> <01c4ed1a$Blat.v2.2.2$4b8d4aa0@zahav.net.il> <87k6r1r7bb.fsf@jurta.org> <87u0q5ruqx.fsf@confusibombus.emacswiki.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1104370587 12056 80.91.229.6 (30 Dec 2004 01:36:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Dec 2004 01:36:27 +0000 (UTC) Cc: Juri Linkov , Eli Zaretskii , drew.adams@oracle.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 30 02:36:20 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CjpEi-0002IQ-00 for ; Thu, 30 Dec 2004 02:36:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CjpPd-000182-GB for ged-emacs-devel@m.gmane.org; Wed, 29 Dec 2004 20:47:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CjpOc-0000lZ-BY for emacs-devel@gnu.org; Wed, 29 Dec 2004 20:46:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CjpOZ-0000k0-LH for emacs-devel@gnu.org; Wed, 29 Dec 2004 20:46:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CjpOZ-0000jZ-Ds for emacs-devel@gnu.org; Wed, 29 Dec 2004 20:46:31 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CjpC9-0007Fn-Ph for emacs-devel@gnu.org; Wed, 29 Dec 2004 20:33:41 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.34) id 1Cjp6R-0000UK-28; Wed, 29 Dec 2004 20:27:47 -0500 Original-To: Alex Schroeder Content-Disposition: inline In-Reply-To: <87u0q5ruqx.fsf@confusibombus.emacswiki.org> User-Agent: Mutt/1.3.28i 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: main.gmane.org gmane.emacs.devel:31593 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31593 On Wed, Dec 29, 2004 at 04:26:14PM +0100, Alex Schroeder wrote: > This sounds a lot like overengineering to me. Assume an innocent user > who takes his face definitions from one system to the next. Depending > on what kind of system it is, his faces will either look like what he > customized them, or it will look like the default definitions for that > kind of system. ... > In my opinion, we don't need to change anything. It seems that it's hard to do perfectly without using "show all display specs" -- whether it changes only the current spec, or overwrites everything, it's probably going to screw up half the time. However, I've definitely been burned by the current rather destructive behavior. I'll carefully customize several different specs (say tty and default), and then _once_ I'll forget to use show-all-display-specs when tweaking some minor detail, and -- whoops! -- all my other customizations will be lost. Perhaps a good method might be this: Default to show-all-display-specs _if_ the user has changed anything; if a face is still completely defaulted, just show the current environment's spec case (as it does now). That way, the first time the user customizes a face, it will overwrite all specs for that face with a single case, applying in all environments. If he later wants to change something, it will show all display specs, but that will be almost the same as not doing so, because there will only be the single default entry due to his previous customization. If he later adds a new display-spec case (which will be easy, as the "add case" widget will already be active), it will then be displayed and shown for subsequent customizations, but that will presumably not be too confusing, as all specs shown will have been added by the user. Since on average, such behavior would be almost the same as the current behavior, this wouldn't be a drastic change either. -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen