From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: About the :distant-foreground face attribute Date: Mon, 13 Jan 2014 18:34:38 -0800 Message-ID: <52D4A23E.4030802@dancol.org> 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; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1389666900 27558 80.91.229.3 (14 Jan 2014 02:35:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 02:35:00 +0000 (UTC) Cc: Eli Zaretskii , Chong Yidong , emacs-devel To: Drew Adams , =?ISO-8859-1?Q?Jan_Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 14 03:35:08 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 1W2tqN-00062p-Hv for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 03:35:07 +0100 Original-Received: from localhost ([::1]:46213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2tqN-0002W1-5a for ged-emacs-devel@m.gmane.org; Mon, 13 Jan 2014 21:35:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2tqJ-0002US-HC for emacs-devel@gnu.org; Mon, 13 Jan 2014 21:35:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2tqH-0001Wr-Jy for emacs-devel@gnu.org; Mon, 13 Jan 2014 21:35:03 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:55163) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2tq7-0001Tt-Tn; Mon, 13 Jan 2014 21:34:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=N+89JvXzWufjNRxm8XNhNENW+wm3BMKiWv2tcB/p/uI=; b=XxxYgEkoK9qCy1pslAysVUo20alNvZwcdZroa/yalc1UCabvr2/NZPpuZeb2zHDJthKoHQqM0zOcpE2WsuP4Ru8Z1iOsZnSqv4gNWufI0tQTMeY6ml3gc7rZLrQsQmjBjb1IRhXkIofBtWWbHa7brk6onrNtmYAymqBCbDP/TryI6G5MbZZKuWguj9OyUfCKVMwTAPgfOj9GvF71yF/e9cwJuPzcHo/jlOXAiZSgLPnqZr8F4jDHpwtvtzuj29ApAn290GGtZDjHh+Uyj14jHDJzXd3PLMpBwPBdaC1FORTpuCEhWIgpL+w2wIEMvXfsLUip+3PmtfP0kZftp3DolA==; Original-Received: from [2620:0:1cfe:a0:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W2tq4-0001Dh-5w; Mon, 13 Jan 2014 18:34:48 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:168337 Archived-At: It sounds like we're in broad agreement on the mechanism. Now let's talk about default policy. On 01/13/2014 05:32 PM, Drew Adams wrote: >>> Region highlighting should never be overridden by font-lock >>> highlighting. >> >> 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. 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. >>> 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. I still don't understand exactly what you're proposing. Here are our options: 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. 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. 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 because the system background color is chosen independently of font-lock's face colors. We can 3a) do nothing and make users customize either their system selection color, Emacs region face, or font-lock color scheme 3b) Automatically adjust foreground colors when the region face is in effect so that they're legible against the system selection background color. This is the policy my patch makes Emacs use by default and it's the one I prefer. 3c) Switch to the system selection foreground color when the foreground color we would otherwise use would be illegible against the system selection background color. My patch can support this policy, and it's the only policy :distant-foreground supports. 3d) Adjust the region face background color until it's legible against all font-lock faces? I *think* this is what you're proposing, but it doesn't make any sense. If we diverge from the system selection background color, we've already lost the integration benefit and should just use option #1 above. 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? >> 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. > > 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. If we ship configuration 3b, we won't set a foreground color and we'll use the specified region background color (which will come from the system) and the font-lock supplied foreground unless the foreground would be illegible against the background. In this case, we adjust the foreground color until it's legible. If a user wants to customize the selection color and uses M-x customize-face RET region RET, she'll be able to set foreground and background independently. If she unchecks :contrast-function, we will always use those colors exactly. If she leaves :contrast-function set, Emacs will always use her specified colors unless, again, the combination would be illegible, and in this case, Emacs will adjust the foreground color until it becomes legible. But why would she select a foreground and background colors combination that is illegible in the first place? >> 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? It depends on the configuration we ship. > A face being equal to its default setting does not imply > that the user gives Emacs license to change it. 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. > 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. I'm in favor of shipping defaults that create a good user experience. If a user never expressed a preference with respect to foreground and background colors, there's no contract to violate. >> 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? 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. 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. > It is important that no face, including `region', have a > non-nil :contrast-function by default. I disagree. Putting it on :region by default is perfectly fine. Remember that the attribute has no effect unless the result would otherwise be illegible. >>> 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. > > 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. The C code already has functionality to compute the exact face used to render a particular location in a particular buffer in a particular frame. We could expose this functionality to lisp if there were a good use case. But right now, 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? 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. > Still, this sounds better than what has been proposed so far. Thanks.