From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: propose adding Icicles to Emacs Date: Tue, 19 Jun 2007 15:48:07 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1182293410 7527 80.91.229.12 (19 Jun 2007 22:50:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 19 Jun 2007 22:50:10 +0000 (UTC) Cc: juri@jurta.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 20 00:50:08 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I0mWT-0007tU-Uc for ged-emacs-devel@m.gmane.org; Wed, 20 Jun 2007 00:50:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I0mWT-0007K4-Ir for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2007 18:50:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I0mVr-0006RV-OA for emacs-devel@gnu.org; Tue, 19 Jun 2007 18:49:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I0mVp-0006QO-CE for emacs-devel@gnu.org; Tue, 19 Jun 2007 18:49:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I0mVp-0006QD-6q for emacs-devel@gnu.org; Tue, 19 Jun 2007 18:49:25 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I0mVn-0008Hw-NW; Tue, 19 Jun 2007 18:49:24 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l5JMnKjn024113; Tue, 19 Jun 2007 16:49:20 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5JMnHC4002583; Tue, 19 Jun 2007 16:49:17 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-80-227.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2970449511182293292; Tue, 19 Jun 2007 15:48:12 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: Linux 2.4-2.6 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:73356 Archived-At: > The current code handles all cases acceptably. It sounds like your > method is better in most cases, but much worse in a few cases. > As it is, we cannot use it. > ... > However, maybe someone can turn your feature into a good one by adding > a special case check for the cases that look bad with your code, and > treat them differently. The result could be a feature that is always > acceptable, while still having the same benefits in the usual case. > That would be something we could install. Uh, just how would you determine "the cases that look bad"? How would the code tell whether a particular somewhat-light yellow foreground looks bad against a not-too-dark cyan background that the user might happen to use for *Completions*? Or would you just treat the "simple" cases where the face foreground and background (or nil for either) are _identical_ to the current *Completions* foreground and background (or nil for either)? Juri's point was not only that `border' showed black on black, but also that some face names were difficult to read because of the particular combination with the *Completions* foreground or background. Trying to do what you suggest is, IMO, (1) a nightmare to try to do right and (2) likely to be an unsuccessful compromise in any case. Not to mention that this kind of thing depends on one's eyesight, the ambient room lighting, monitor qualities, personal tolerances and preferences, the moon phase, presence or absence of related fatwahs,... Users will cry out for ways to customize this, and the result of trying to allow for that will likely be a mess too. Sorry to be negative, but I suspect that that way lies madness. Stefan's suggestion of a separate swatch is much better, IMO. I've implemented that - see my other mail on this.