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: Tue, 14 Jan 2014 02:44:15 -0800 Message-ID: <52D514FF.7010404@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> <52D4EBA9.8050802@swipnet.se> <52D4F2C2.8080800@dancol.org> <52D504A7.80104@swipnet.se> 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 1389696267 31213 80.91.229.3 (14 Jan 2014 10:44:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 10:44:27 +0000 (UTC) Cc: Eli Zaretskii , Chong Yidong , emacs-devel To: "Jan D." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 14 11:44:35 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 1W31U1-0006Tm-JA for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 11:44:33 +0100 Original-Received: from localhost ([::1]:47425 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W31U1-0007XW-01 for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 05:44:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46279) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W31Tw-0007UZ-Kx for emacs-devel@gnu.org; Tue, 14 Jan 2014 05:44:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W31Tv-0001k9-Bl for emacs-devel@gnu.org; Tue, 14 Jan 2014 05:44:28 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:56404) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W31Tr-0001jR-NT; Tue, 14 Jan 2014 05:44:24 -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=kgTJXYFcNIXF6oEXdkuMkHsBq+qwmvRkZpUTxUFT0gA=; b=TyxTfwQvVZlLeSqsPJjTedW3w6RWpSE1wXVg4N1WXk9R27hDKWPNTkwU8euTA+2i98Wn9AHDuHKE7qg+yNMn4H5sVOkjKh0vOYbnjMQ4Cx7E4nDgnOA4OqEVtPWX8KYUDftpvLB6zDkn9tofqf6a7ANehZcFtD7v19AXLVNjPWCWYpOlhMMSMWnUCcmwvSll4zUn+a1W4H7CG36Lh9Q3w0Agbzf8jg+40jd8QPpW7oHyhodP6VlAu7z9P3d1LClxrbczvGsxd/c6nXo+Jt9MgdTxDhKW5y2ZQsDIsFFzdGdZ+bsxN3pfccBi1jK9F4yTSujPL00FYYW0njxq7V1wUw==; Original-Received: from [2601:8:b200:217:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W31Tp-0001ry-Vd; Tue, 14 Jan 2014 02:44:22 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <52D504A7.80104@swipnet.se> 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:168348 Archived-At: On 01/14/2014 01:34 AM, Jan D. wrote: >>> Given the use case at hand, we know for a fact that the background is >>> the region background, so I don't understand why a calculated foreground >>> is needed. Just pick one that matches the background. >>> There might be other use cases where a calculated foreground makes >>> sense, but my imagination fails me here. >> >> Calculated foreground colors look better: they resemble the font-lock >> colors on which they're based. > > For the region case, that would imply the possibility of different > foregrounds for marked text, none which is the actual font-lock color. It *is* the same color in the sense that the code we generate has the same hue. How on earth is that worse than changing arbitrary font-locked pieces of text to the system selection foreground color? You seem to object to any feature that renders a face in a color other than what's literally written in the face spec. But that's exactly what happens when we put gtk_selection_bg_color in a color spec! Why are you fine with allowing gtk_selection_bg_color as a color (producing a color that's presumably workable but unknown to a theme writer) but adamantly opposed to a feature that selects good colors another way? I've produced working code that allows Emacs to act how you prefer *and* how I prefer based on user configuration. What is your problem with that code? Have you responded to the numerous objections to :distant-foreground with anything other than retrenchment? > Also, "look better" is just subjective, a theme > designer should deside what looks best, not Emacs code. And a theme designer can opt not to use the feature or to explicitly turn it off --- but a theme designer should never have to bother, because the feature only activates when the contrast is awful, which happens only when a theme designer screws up or deliberately relies on system colors. Theme designers can specify what exactly gets rendered in both systems. Why do you care so much about letting theme designers loosen bounds using a special-purpose face attribute (which you don't even bother to mirror for changing backgrounds) instead of a general-purpose mechanism? >>> Again, I really don't see this use case. Do you have one? >> >> I just mentioned one. See my other email, the one where I laid out the >> options for Emacs configuration defaults. > > That is not a use case. A use case describes what an actual user does > and in what situation automatically calculates colors enters the picture. This entire thread describes the use case. There are abundant examples. Your objection here is baseless. >>>> We should push policy to user customization when >>>> possible instead of hardcoding policy in the logic of face attributes. >>> >>> I don't think we do that, users can still customize faces as they see >>> fit. >> >> :distant-foreground has far too narrow a justification to warrant being >> a face property by itself. > > Also, just an opinion, not based on some documented design rule in any > Emacs or GNU document. So only GNU documents count now, not reasoned arguments? What "documented design rule in any Emacs or GNU document" justifies :distant-foreground? > IMHO :stipple is as narrow. :stipple is nothing like what we're talking about.