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: [PATCH] Re: About the :distant-foreground face attribute Date: Mon, 13 Jan 2014 15:01:57 -0800 (PST) Message-ID: References: <87bnzo9cja.fsf@gnu.org> <59B7E7FC-48D0-4737-B1BB-FFAC5BA9E07A@swipnet.se> <874n5f3162.fsf@gnu.org> <83fvozf86g.fsf@gnu.org> <87r48javwe.fsf@gnu.org> <83bnzmfjxe.fsf@gnu.org> <52D3E689.6050902@dancol.org> <8E16225F-53EF-498A-AB35-66EB9B33B859@swipnet.se> <52D43360.6050605@dancol.org> <9BD01B88-AF13-44DD-8DBE-4598BAC136DD@swipnet.se> <52D45C73.6090906@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389654154 29153 80.91.229.3 (13 Jan 2014 23:02:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Jan 2014 23:02:34 +0000 (UTC) Cc: Eli Zaretskii , Chong Yidong , emacs-devel To: Daniel Colascione , =?iso-8859-1?B?SmFuIERq5HJ2?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 14 00:02:40 2014 Return-path: Envelope-to: ged-emacs-devel@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 1W2qWl-0008Qc-Cs for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 00:02:39 +0100 Original-Received: from localhost ([::1]:45489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2qWk-0004r2-VP for ged-emacs-devel@m.gmane.org; Mon, 13 Jan 2014 18:02:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2qWa-0004qm-4s for emacs-devel@gnu.org; Mon, 13 Jan 2014 18:02:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2qWR-0007oE-HV for emacs-devel@gnu.org; Mon, 13 Jan 2014 18:02:28 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:42004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2qWI-0007mz-IV; Mon, 13 Jan 2014 18:02:10 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s0DN1wo7030142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jan 2014 23:02:00 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0DN1vIw024584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jan 2014 23:01:58 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0DN1vfx022437; Mon, 13 Jan 2014 23:01:57 GMT In-Reply-To: <52D45C73.6090906@dancol.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:168327 Archived-At: > Yes, but font-lock colors are specified with explicit colors (even > in the default "theme"), and we want to preserve these even in the > presence of a selection.=20 I, for one, do not want that. I want region highlighting to correctly show which characters have been selected - each character. Region highlighting should never be overridden by font-lock highlighting. UI-101: Intro to User Interfaces. > At the same time, we want to make sure that highlighted text is > legible against a background of whatever the system selection color > happens to be. Then choose the `region' background accordingly. If Emacs cannot do that automatically in the case of some platforms, too bad - let users compensate by setting `region' manually. They should always be the ultimate judge of what works best for them. > The best way to do that is to automatically shift the foreground > colors in value, but not hue, so that they remain legible while > being recognizably the same color. No. The best way to do that is to let users do it - let their preferences rule. Users do not need Emacs changing whatever values they set for the `region' face. And if you say that your new feature does not override user preference for `region', how can you determine that? You cannot just compare the current value to the standard value, since the standard value might in fact be just what the user wants. Who are we to say we know better than the user? > I think the results are actually pretty good. That does not sound like a ringing endorsement. Does that mean that only 25% of user preferences are ignored? 10%? > If a particular theme doesn't want to use automatic color adjustment, > it can specify its own :contrast-function and do whatever it wants. So if it does not specify a :contrast-function, you take that as a license to impose a standard one, instead of as a preference to not perform any :contrast-function twiddling at all? > I would also support a scheme where, by default, 'region' sets > foreground *and* background colors to the system selection colors > and other faces don't show through. But we didn't decide to go in that > direction. How about supporting the time-worn "scheme" whereby users and Lisp code can specify clearly what the region highlighting foreground and background are, literally, with nothing hidden behind their backs playing tricks on them? IOW, treat `region' like other faces, and treat its foreground and background equally. > > If you talk about other themes, they can set :distant-foreground > > to a real color of their choosing and not rely on some automatically > > generated one which most probably don't fit the theme anyway. > > Automatically generated colors are a crutch which should be avoided > > if possible, certainly not recommended. >=20 > There's no way that themes can take into account all the possible > colors users and packages might use. Automatic contrast adjustment > can do that. Bzzzzzt! No, but thanks for playing. Automatic contrast adjustment can never respect all user (or package) `region' specs, precisely because it *automatically adjusts* the appearance away from what users (or packages) specify. > If you want the :distant-foreground behavior, it can be accommodated > in this patch. This patch also permits other schemes that some users > might find more useful. We should push policy to user customization > when possible instead of hardcoding policy in the logic of face > attributes. We should leave face specs defined by users and packages well enough alone. Let them decide what they want - and let them get what they want, without the "benefit" of behind-the-back twiddling. Users deserve honest transparency, not parlor magic tricks.