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: About the :distant-foreground face attribute Date: Sun, 12 Jan 2014 13:20:08 -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> <87bnzlyvwb.fsf@gnu.org> <83wqi9cakl.fsf@gnu.org> <87zjn5584t.fsf@gnu.org> <8738kwydon.fsf@engster.org> <871u0dwiyv.fsf@engster.org> <87fvot2c18.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389561644 19830 80.91.229.3 (12 Jan 2014 21:20:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Jan 2014 21:20:44 +0000 (UTC) Cc: jan.h.d@swipnet.se, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Chong Yidong , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 12 22:20:49 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 1W2SSf-0001Uz-8M for ged-emacs-devel@m.gmane.org; Sun, 12 Jan 2014 22:20:49 +0100 Original-Received: from localhost ([::1]:39512 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2SSe-00022d-R4 for ged-emacs-devel@m.gmane.org; Sun, 12 Jan 2014 16:20:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2SST-0001yM-J3 for emacs-devel@gnu.org; Sun, 12 Jan 2014 16:20:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2SSK-0002Qj-EZ for emacs-devel@gnu.org; Sun, 12 Jan 2014 16:20:37 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:34497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2SSA-0002Mh-To; Sun, 12 Jan 2014 16:20:19 -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 s0CLKHOZ002350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Jan 2014 21:20:17 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0CLKFD6024415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jan 2014 21:20:16 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s0CLKFwi008680; Sun, 12 Jan 2014 21:20:15 GMT In-Reply-To: <87fvot2c18.fsf@gnu.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:168248 Archived-At: > Instead, here's a compromise proposal: >=20 > - Allow :foreground to take the value of (fallback COLOR) or > something like that, which would be equivalent to setting > :foreground to unspecified and :distant-foreground to COLOR. I think you are saying to set the face's foreground attribute to whatever the dwim thingie calculates, which is what I suggested too. Is that what you mean? > (We still need a replacement term for "distant foreground". As > mentioned before, this term sounds nonsensical.) Yes, if a term is needed at all. IIUC, there would be no new face attribute, at least. The ordinary foreground attribute would be given whatever clever value is deemed more appropriate, right? So if a new term is needed for this clever color, then that would be only for, say, a function name and its doc, not for a new face attribute - right? > - In order to avoid incompatibilities, set the :foreground of the > `region' face to "*_selection_fg_color". I don't know what the latter is. Not that I necessarily need to. I've already expressed my concerns, and am hoping that they are taken into account in some way. I have confidence that you, at least, understand what my concerns are and will think about them. > In other words, avoid using the above feature in the `region' > face, at least for Emacs 24.4. I guess you are saying that the region foreground will not be adapted automatically to compensate for an unfortunate region background default choice. For Emacs 24.4, at least. Is that right? > The rationale is that (i) we can live with having a fixed > foreground color for the `region' face, since that was the > case in Emacs 24.3 on GTK anyway. Can't we live with that as a continuing feature? That sounds like TRT, to me. Let's not forget that the user can define the `region' face any way s?he wants. It is not only the foreground that can "conflict", and it is not only the background that might be defined. Similarly, font-lock highlighting can use faces with backgrounds defined, as well as foregrounds. Would this clever feature do the same thing for letting font-lock backgrounds show through as it aims to do for letting font-lock foregrounds show through? If not, why not? There is nothing inherently asymmetrical between foreground and background, for either face `region' or font-locking. > And (ii) not using this feature immediately gives > third-party packages a "transition period" to adapt to its > presence, Which means what? > without immediately failing by encountering it in a standard > face. What is it that will eventually be encountered in a face, standard or otherwise? Are back to an additional face attribute? Sorry, but I don't understand the proposal. What is it, in concrete terms (user terms, Lisp terms)? What will 3rd-party code need to know? What adaptation is needed, in general terms at least? > If there are no objections, I can implement this. I replied so that you know that I don't yet understand what is being proposed. I understand that you had problems with this new feature, as implemented (you filed the bug report). So I suppose that you will DTRT. Still, I would like to understand what the change will be, if possible.