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: Tue, 14 Jan 2014 11:32:31 -0800 (PST) Message-ID: <2798eddb-c6c7-4b73-8bd0-e4bd72f3405e@default> 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> <52D4A23E.4030802@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 1389728002 3407 80.91.229.3 (14 Jan 2014 19:33:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 19:33:22 +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 20:33:28 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 1W39jr-0000Hs-1p for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 20:33:27 +0100 Original-Received: from localhost ([::1]:50319 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W39jq-0005tx-La for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 14:33:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W39jO-0005AB-Q3 for emacs-devel@gnu.org; Tue, 14 Jan 2014 14:33:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W39jG-0005mJ-2a for emacs-devel@gnu.org; Tue, 14 Jan 2014 14:32:58 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:38195) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W39j6-0005k9-Ul; Tue, 14 Jan 2014 14:32:41 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0EJWX9D010394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jan 2014 19:32:33 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s0EJWWqK012810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 19:32:33 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s0EJWWC3012794; Tue, 14 Jan 2014 19:32:32 GMT In-Reply-To: <52D4A23E.4030802@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: ucsinet22.oracle.com [156.151.31.94] 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:168386 Archived-At: > > 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. >=20 > I don't have a strong opinion about the default, although I lean > toward the behavior #3 (3b specifically) below since it looks > blingy and might help attract new users. Bof. Today's sparkling blingy is tomorrow's annoying. But the real problem is selection highlighting not showing you exactly what is selected - each char, because font-locking can override it, making it seem to disappear here or there. > I still don't understand exactly what you're proposing. Here are our > options: >=20 > 1) We can ship Emacs with hard-coded defaults for region's > foreground and background colors and ignore system settings. This > arrangement will produce legible text, and there's no need to adjust > region's colors. >=20 > 2) We can ship Emacs such that it uses the system selection > foreground and background colors for region. This arrangement will > also produce legible text, and there's no need to adjust region's > colors. Yes. #1 or #2 - only. I personally do not care about or for #2, but if it is important to some users or some platforms, that's OK by me - if, as you say, it presents no problems. > 3) We can ship Emacs such that it uses the system selection > background color and uses font-lock colors for foreground text. > This arrangement will sometimes produce an illegible result... Not #3, IMO. There is no need to give priority to font-lock highlighting over the selection highlighting. That's just asking for trouble, and will confuse users. Font-lock can use any colors for either foreground or background, so there will always the possibility that some selection highlighting will "disappear", not showing you some chars as having been selected. And YAGNI. Sounds like cool bling to you (today). Not useful. Problematic. Just one opinion, of course. > So to put the discussion in more concrete terms: say I run a stock > GTK3 Emacs on a system with a background color exactly equal to > "Blue1", which is the color we use for font-lock-function-name-face. > I visit xfaces.c, search for "UNSPECIFIEDP", and hit C-a C-SPC C-e. > What colors do you propose we use for the text "UNSPECIFIEDP" on > that line? See #1 and #2 above. And note that the "problem", of text highlighted by the selection (region) having foreground and background the same, is the same problem you will anyway encounter for Isearch. In your example, even when searching you can run into the same problem. Will you be proposing that Isearch highlighting too let font-lock highlighting show through? There is a reason we give Isearch highlighting such a high priority: it should clearly _highlight_ text - even text that might be font-locked. And will you be proposing the same thing for secondary-selection highlighting? And what about Isearch over text that is in the region or the secondary selection? Font lock highlighting is not about selecting text. It should not (certainly not by default) show through a selection highlight. > > A face being equal to its default setting does not imply > > that the user gives Emacs license to change it. >=20 > I disagree. If our user leaves a face at the default setting, she's > giving us *explicit license* to use whatever heuristics we think > work best. And how does she specify to you that the default colors are exactly what she happens to prefer? How does she produce the same effect as if the default colors were different and she customized them to be what the default colors actually are? How does she tell you "Hands off! This is really what I want!"? > > 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. >=20 > I'm in favor of shipping defaults that create a good user > experience.=20 A novel opinion, to be sure. ;-) > If a user never expressed a preference with respect to foreground > and background colors, there's no contract to violate. And how does she express that preference, if it happens to coincide with the default colors? What you are saying is like saying that you think you have a license to change the value of option `default-frame-alist' automatically, if the current value is nil, because that's also the default value. I do not see it that way. Coincidence of the current value with the default value does not imply that the user does not care. That's just faulty logic. And perhaps over-eagerness to do clever dwimmy things for the user's "benefit". > >> 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? >=20 > Right now, it depends on the order in which the faces are merged. > The last face that specifies a :contrast-function gets to control the > contrast behavior. Users are going to have trouble with that complication. Too much wondering about what happened and why. Of course, I could be wrong. > Right now, region is the only face that specifies a > contrast-function, and I can't think of another good use case at > the moment. Maybe that in itself should tell you something... > > 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. >=20 > I don't understand why lisp code would need to know the > post-adjustment colors used for display. Can you explain why > we'd want to know? Lisp code that checks or changes a given color attribute is trying to check or affect the actual appearance of the face (again, not considering merges with other faces etc.). Doing this breaks the one-to-one relationship between the face's attributes and its appearance. That means that the Lisp code cannot just examine or set `foreground' and `background' colors. It will need to be changed to also invoke the :contrast-function. Or if that takes effect automatically, it will need to be aware that that can happen, and perhaps even accommodate it to cancel it out (depending on the purpose of the Lisp code). Consider code that does something based on distance of the current foreground appearance from some given value - the same kind of thing you are doing with a given :contrast-function, for instance. It will no longer be sufficient to just measure the distance to the current `foreground' attribute value. Now, it will need to invoke the current :contrast-function too, to accurately estimate the distance. > Also, today, any lisp code that wants to mimic the redisplay face > combination logic needs to take into account text properties, > frame-local variables, overlays, display attributes, and so on. It > would be a big job, and I'm not aware of anyone who's done it. I specifically spoke of the color attributes for an individual face, and separated this from combining faces and other display properties. Consider a Lisp function that helps you customize the foreground and background colors of an individual face. What it checks and what it produces should reflect the face appearance (again, in isolation). Consider a function that lets you modify the foreground of a given face incrementally, showing you the effect, WYSIWYG-style, in your buffer of C code or whatever. Maybe it increments hue or saturation or the blue component. With your feature, what you see by its changing attribute `foreground' will presumably "jump" when the :contrast-function decides that the new value would be too close to the background. I don't say that these things are insurmountable. I'm just saying that this adds something new to take into account. It might or might not break some existing code (in terms of intention, at least).