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 17:32:09 -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> <52D47289.2020700@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 1389663170 23186 80.91.229.3 (14 Jan 2014 01:32:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 01:32:50 +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 02:32:54 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 1W2ssA-0004JN-9k for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 02:32:54 +0100 Original-Received: from localhost ([::1]:45945 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2ss9-0007qW-Au for ged-emacs-devel@m.gmane.org; Mon, 13 Jan 2014 20:32:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2sry-0007q6-BQ for emacs-devel@gnu.org; Mon, 13 Jan 2014 20:32:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2srp-0001wC-No for emacs-devel@gnu.org; Mon, 13 Jan 2014 20:32:42 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:39099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2srg-0001tK-G9; Mon, 13 Jan 2014 20:32:24 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0E1WDjI002253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jan 2014 01:32:15 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0E1WAVE012207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 01:32:11 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0E1WAGk017880; Tue, 14 Jan 2014 01:32:10 GMT In-Reply-To: <52D47289.2020700@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: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:168334 Archived-At: > > Region highlighting should never be overridden by font-lock > > highlighting. >=20 > You can configure Emacs to act that way. Emacs should act that way by default, as it always has. Anyone who wants automatic foreground twiddling for a given face should ask for that explicitly. Whether that twiddling is to accommodate font-locking or for some other reason. (Likewise, for face filtering, if this feature ends up going that way in order to generalize the function and give it access to and effect over all face attributes.) > > 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. >=20 > If we choose a region background that works with traditional font- > lock colors, that background color cannot come from the system. Just don't do that. Certainly not by default. > If we want the region background color to come from the system, > we have to have some way of making it contrast with the > foreground. What has Emacs done in the past? Since Emacs can specify the default background and foreground, it should be trivial for it to come up with two colors that contrast. And even two colors that contrast and are different from the default (e.g. system) background. If Emacs on some system (how many are a real problem?) really cannot find a default `region' background and foreground that work, then punt and let the user try. How have we gotten by for almost 4 decades without this feature? It's hard to believe that a contrasting pair of default colors cannot be found. Just take the font-lock nonsense out of the equation, and there should be no problem - that's my guess. > Emacs won't change any colors users set on the region face. > If a user sets the region's foreground and background colors, > Emacs will use those colors for the selection.=20 Glad to hear you say that. And what if the default `region' foreground and background are exactly what the user wants? Does s?he have to jump through a hoop to "set" face attributes to what they already were, just to say "Hands off!"? She shouldn't have to. > We are talking specifically about the case where users do > *not* specify a foreground color for region. And what does "not specify" mean? Does it mean only that the value has not changed from the standard (default) value? Or does it mean that users somehow explicitly let you know that they do not mind if you twiddle their region? A face being equal to its default setting does not imply that the user gives Emacs license to change it. IMO, any such feature should be opt-in, not opt-out. A user should not need to explicitly do anything to stop Emacs from twiddling her region. She should ask for twiddling if she wants that. > Emacs adjusts colors only when a :contrast-function is set > for some face applying to a particular character and that > face isn't overridden by one that sets :contrast-function to > nil. OK, that sounds a bit better, at least. So if any face has a nil :twiddle-me, er sorry, :contrast-function attribute, and that face is merged with a face that has a non-nil one, the nil one wins and there is no twiddling. Is that right? It is important that no face, including `region', have a non-nil :contrast-function by default. > Set foreground and background. Uncheck :constrast-function if > you want So it is easy for a user or Lisp code to turn this off. Good. Now let's turn it off by default. It will be just as easy for a user to turn it on, if s?he wants. > If a user or package doesn't want automatic contrast > adjustment, either don't ask for it or explicitly turn it off. Don't ask for it (i.e., do nothing) sounds good, to keep it off. Off by default. Explicitly turn it on if you want it. What you describe now sounds a bit like what I suggested a week ago: >> And that user control should be *per face*. One should not >> be obliged to choose either preventing the overriding or >> allowing it for all faces. The choice should be a function >> of the particular face. Now *that* could be done using a >> new face attribute, if you want. (Or a function.) This is OK as long as any long-existing faces such as `region' will not have non-nil :contrast-function attributes by default. Let users who really want their region twiddled opt into that.=20 But it still makes life more complicated for Lisp code that wants to get or set the actual appearance of the face. Whereas before code needed only to get or set attribute :foreground, now it will need to also check for a non-nil :contrast-function and apply that. Still, this sounds better than what has been proposed so far.