From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 03 17:21:59 2017 Received: (at submit) by debbugs.gnu.org; 3 Jan 2017 22:21:59 +0000 Received: from localhost ([127.0.0.1]:40631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOXSx-0004Ew-4b for submit@debbugs.gnu.org; Tue, 03 Jan 2017 17:21:59 -0500 Received: from eggs.gnu.org ([208.118.235.92]:34624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOXP4-00048M-Ts for submit@debbugs.gnu.org; Tue, 03 Jan 2017 17:17:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOXOy-0002A5-Oc for submit@debbugs.gnu.org; Tue, 03 Jan 2017 17:17:53 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:51295) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cOXOy-0002A0-Kw for submit@debbugs.gnu.org; Tue, 03 Jan 2017 17:17:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOXOx-0006aV-Ho for bug-gnu-emacs@gnu.org; Tue, 03 Jan 2017 17:17:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOXOw-00029V-Ha for bug-gnu-emacs@gnu.org; Tue, 03 Jan 2017 17:17:51 -0500 Received: from mail-qt0-x22c.google.com ([2607:f8b0:400d:c0d::22c]:35973) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cOXOw-00029J-DG for bug-gnu-emacs@gnu.org; Tue, 03 Jan 2017 17:17:50 -0500 Received: by mail-qt0-x22c.google.com with SMTP id k15so236820861qtg.3 for ; Tue, 03 Jan 2017 14:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=IwUOQWCho3BK/rf/3I3tb/JP161zQro/Ne9KiCArN6c=; b=pzQIbSgkUf/0Kg/C+7oOq+e3ivAMG5obwacPVJvN4vpXJFkNrgFcMNMNtljvFCqGRi Ngxawi9nFEiDQixHrAB/K7n7heUS93WQBymd+mzp3qMbRT4MbPzIU9apgJAoLou3J5so VYacB6HYdo0A4vR6EacE/lcPMWoJ7bueLyS+KuQenEgyOnr4YxRepdPKNV5bnr8XmZ1c /DkgMU4AMxgf919paD5fmfImx9nDYfib7ZH8orYcVIhpbXDucJ9FewhccoIn0ZrDzEw5 WppQYI3aqPAnJyjs2OFn8toU1cHrc7FOdMRpaMG6yEIRdL4hr6+MdK0pMd6tBDiDFRH6 ppOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=IwUOQWCho3BK/rf/3I3tb/JP161zQro/Ne9KiCArN6c=; b=E0hA4bt9sklb2F6BV9nFjMyAd2SvJ8FVsRat7cNnWKU778t5cA4pzRvCY0MOTdmN6S boEvoesx9M7Jmczh1Xx7wbo2YUsWzT7P4axUZugHH9CsxcV76TD/Pe/cguUEw5Vb8eLl woE8CZyodWVO6Nj+pKrt6yG4LQFWzzZ9B7X4y7WFXdEz4wec+Fk0/RPhUH+SQkYROQYt InvuJAHO6XUtdr8WZcEWTMuyTODzVCRK71pBaVNGnTNxP1HL7vr9iWxcOzQfQPbeY3rZ OzP2fOrWTTlrSyHnn0HVx2dOHpCnR6QcAanqm+YZLinKBhKplx0y+F6/TWofnc2W1AhS 2Z6Q== X-Gm-Message-State: AIkVDXLME3nV0zB7Ij/o4StkwZP+ATxrvcUaoqxPPyGre1cCbcSYhxKnDcx95F5yGTVy8guBqUlfPUBqC3wE5Q== X-Received: by 10.237.55.97 with SMTP id i88mr60372792qtb.143.1483481868295; Tue, 03 Jan 2017 14:17:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.164 with HTTP; Tue, 3 Jan 2017 14:17:07 -0800 (PST) From: Travis Foster Date: Tue, 3 Jan 2017 14:17:07 -0800 X-Google-Sender-Auth: LzILvMhwFbVvkcMoBrepO-R2a3c Message-ID: Subject: `display` property faces are prioritized above overlays To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary=001a113facc0ca644d054538092e X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Tue, 03 Jan 2017 17:21:57 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --001a113facc0ca644d054538092e Content-Type: text/plain; charset=UTF-8 When I do the following (for example): (put-text-property (point) (1+ (point)) 'display (propertize "." 'face 'header-line)) The character at point becomes a dot with a gray background. If I then enable hl-line-mode, the line turns green, as expected. However, the dot still has a gray background; it does not turn green with the rest of the line. It appears that hl-line-mode uses an overlay to highlight the line. From the overlay documentation, "Currently, all overlays take priority over text properties." But it seems like in this case, the display text property is taking priority over the the overlay. Since I'm embedding the face into the display string, I expect it to take priority over any faces that are applied to the text, but not over any overlays which affect it. --001a113facc0ca644d054538092e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When I do the following (for example):

= (put-text-property (point) (1+ (point)) 'display (propertize ".&qu= ot; 'face 'header-line))

The character at = point becomes a dot with a gray background. If I then enable hl-line-mode, = the line turns green, as expected. However, the dot still has a gray backgr= ound; it does not turn green with the rest of the line.

It appears that hl-line-mode uses an overlay to highlight the line. F= rom the overlay documentation, "Currently, all overlays take priority = over text properties." But it seems like in this case, the display tex= t property is taking priority over the the overlay. Since I'm embedding= the face into the display string, I expect it to take priority over any fa= ces that are applied to the text, but not over any overlays which affect it= .
--001a113facc0ca644d054538092e-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 03 17:30:08 2017 Received: (at 25348) by debbugs.gnu.org; 3 Jan 2017 22:30:08 +0000 Received: from localhost ([127.0.0.1]:40636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOXap-0004Rv-Vl for submit@debbugs.gnu.org; Tue, 03 Jan 2017 17:30:08 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:18098) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOXan-0004Q8-J4 for 25348@debbugs.gnu.org; Tue, 03 Jan 2017 17:30:06 -0500 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v03MTvur007379 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Jan 2017 22:29:58 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v03MTvUR031493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Jan 2017 22:29:57 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v03MTuFk022388; Tue, 3 Jan 2017 22:29:57 GMT MIME-Version: 1.0 Message-ID: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> Date: Tue, 3 Jan 2017 14:29:55 -0800 (PST) From: Drew Adams To: Travis Foster , 25348@debbugs.gnu.org Subject: RE: bug#25348: `display` property faces are prioritized above overlays References: In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -6.7 (------) X-Debbugs-Envelope-To: 25348 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.7 (------) > When I do the following (for example): > (put-text-property (point) (1+ (point)) > 'display (propertize "." 'face 'header-line)) ... > But it seems like in this case, the display text property > is taking priority over the the overlay. You are using a "replacing" `display'-property spec. See (elisp) `Replacing Specs'. http://www.gnu.org/software/emacs/manual/html_node/elisp/Replacing-Specs.ht= ml Your text that has the property is entirely replaced (for display) by what is specified for property `display'. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 03 17:53:14 2017 Received: (at 25348) by debbugs.gnu.org; 3 Jan 2017 22:53:14 +0000 Received: from localhost ([127.0.0.1]:40643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOXxB-0004xa-UM for submit@debbugs.gnu.org; Tue, 03 Jan 2017 17:53:14 -0500 Received: from mail-qk0-f181.google.com ([209.85.220.181]:32790) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOXxA-0004xN-En for 25348@debbugs.gnu.org; Tue, 03 Jan 2017 17:53:12 -0500 Received: by mail-qk0-f181.google.com with SMTP id t184so390780560qkd.0 for <25348@debbugs.gnu.org>; Tue, 03 Jan 2017 14:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=DVGfnPHx3kGul+z2hLjN7JKbdcmhzG5OpAKBXE8dgVk=; b=uDAM8z9JkNxOwRlHV8jbMJDjt0CbewODeNC0/ZTXuplrvMfc1QOpA0jkSbJ2W8C+Gw BJU7/m7QFPzNcEtWnF3ssZK73N50L30QEYAUMHcVElHF8OIcE5GkFysCMbKphEQ+U2XM qK8o85jcL4fIeR72myhHhrJPElZV0V82oeAUPVixa3HX9uoOd+bek7h42VNNlovpPc6I FLKyZ1m9drfZsUz9zJ4ogXCpxUMIIzByQpbKTYu9IvxEilSHKHK/sIX6AzH3fBgk2Y5D WZ+4nT6cC9ydg5TOgEMtmj0GMGjna9AZXcRV+tdqhvcj6gvbbvQbKQ3SuaQFg9PtkSdn 3DyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=DVGfnPHx3kGul+z2hLjN7JKbdcmhzG5OpAKBXE8dgVk=; b=Pllx93XaU57Y6U7GWbMlM3WoTEj1CvmXUoQ3GxrjvCIpTiONdWsyBmLqnQYtHpsQXZ 58PfZI24vvZIHUINWDR1+OfTF+boBfsYLUflSLW0csXMc7VU0sq8ABrONGLbVsIOKZxg TlKw+Yh5ym6sJgggmHBh1iH3a+MSnUvKx0irhCnd8eE7vLDU2pa8j4FAtosCRlM9pkrA 95Jx7HoaPRCvPD3KHpfJdXF43ri9/C9vxeYvhiTeJpdiTVYA53xkDdyTA6y5+KoGxJcB 3Qm7ulU87C8T5jKHe91XyTRiaAlJ2uCDNXJWM1TD1UnucfBrRP/XtUJ9Y+TSK1nOFip6 6UUg== X-Gm-Message-State: AIkVDXJ0qV6QSDeanogoHzn+F8nKHr0BXSJwoeqLniEsKl6pEwTVZ+wDYbu+W1mC0fUn/1dqiQJms/fDbk0fjA== X-Received: by 10.55.204.13 with SMTP id r13mr61421016qki.260.1483483986804; Tue, 03 Jan 2017 14:53:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.164 with HTTP; Tue, 3 Jan 2017 14:52:26 -0800 (PST) In-Reply-To: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> From: Travis Foster Date: Tue, 3 Jan 2017 14:52:26 -0800 X-Google-Sender-Auth: paM7z9Mg2buXEXomsZrF_x2nM3g Message-ID: Subject: Re: bug#25348: `display` property faces are prioritized above overlays To: Drew Adams , 25348@debbugs.gnu.org Content-Type: multipart/alternative; boundary=001a1149a3921046c7054538887a X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25348 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --001a1149a3921046c7054538887a Content-Type: text/plain; charset=UTF-8 Yes, the text in the buffer is replaced by its display text, with the face. Then, I would expect the overlay to apply to all the text on the line, including the replacement text. Since the properties in overlays are supposed to take priority over the properties in the buffer itself, I don't think it makes sense for the replacement to take priority over the overlay. Is that wrong? It seems that the replacement should occur, and then the resulting text should be modified further by the overlay. On Tue, Jan 3, 2017 at 2:29 PM, Drew Adams wrote: > > When I do the following (for example): > > (put-text-property (point) (1+ (point)) > > 'display (propertize "." 'face 'header-line)) > ... > > But it seems like in this case, the display text property > > is taking priority over the the overlay. > > You are using a "replacing" `display'-property spec. > See (elisp) `Replacing Specs'. > http://www.gnu.org/software/emacs/manual/html_node/elisp/ > Replacing-Specs.html > > Your text that has the property is entirely replaced (for display) > by what is specified for property `display'. > --001a1149a3921046c7054538887a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, the text in the buffer is replaced by its display tex= t, with the face. Then, I would expect the overlay to apply to all the text= on the line, including the replacement text. Since the properties in overl= ays are supposed to take priority over the properties in the buffer itself,= I don't think it makes sense for the replacement to take priority over= the overlay.=C2=A0Is that wrong? It seems that the replacement should occu= r, and then the resulting text should be modified further by the overlay.

On Tue, Jan 3= , 2017 at 2:29 PM, Drew Adams <drew.adams@oracle.com> wr= ote:
> When I do the following (for ex= ample):
> (put-text-property (point) (1+ (point))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &= #39;display (propertize "." 'face 'header-line))
...
> But it seems like in this case, the display text property
> is taking priority over the the overlay.

You are using a "replacing" `display'-property spec.
See (elisp) `Replacing Specs'.
http://www.gnu.org/soft= ware/emacs/manual/html_node/elisp/Replacing-Specs.html

Your text that has the property is entirely replaced (for display)
by what is specified for property `display'.

--001a1149a3921046c7054538887a-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 11:06:30 2017 Received: (at 25348) by debbugs.gnu.org; 4 Jan 2017 16:06:30 +0000 Received: from localhost ([127.0.0.1]:41306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOo58-000882-AM for submit@debbugs.gnu.org; Wed, 04 Jan 2017 11:06:30 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOo57-00087k-9r for 25348@debbugs.gnu.org; Wed, 04 Jan 2017 11:06:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOo4x-0001V3-Dd for 25348@debbugs.gnu.org; Wed, 04 Jan 2017 11:06:24 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOo4x-0001Uo-As; Wed, 04 Jan 2017 11:06:19 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3323 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cOo4w-0005bm-Hh; Wed, 04 Jan 2017 11:06:18 -0500 Date: Wed, 04 Jan 2017 18:06:31 +0200 Message-Id: <83vatuernc.fsf@gnu.org> From: Eli Zaretskii To: Travis Foster In-reply-to: (message from Travis Foster on Tue, 3 Jan 2017 14:52:26 -0800) Subject: Re: bug#25348: `display` property faces are prioritized above overlays References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-Debbugs-Envelope-To: 25348 Cc: 25348@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > From: Travis Foster > Date: Tue, 3 Jan 2017 14:52:26 -0800 > > Yes, the text in the buffer is replaced by its display text, with the face. Then, I would expect the overlay to apply > to all the text on the line, including the replacement text. Since the properties in overlays are supposed to take > priority over the properties in the buffer itself, I don't think it makes sense for the replacement to take priority > over the overlay. Is that wrong? Drew is right: the priority of overlays over text properties only comes into play when both text properties and overlays are set on the same region of text. In your case, the 'face' property is put on a display string, whereas the hl-line overlay is on buffer text. So priority considerations don't apply here. > It seems that the replacement should occur, and then the resulting > text should be modified further by the overlay. Emacs uses the face from the overlay only for text to which this overlay is applied. The display string is therefore using its own face definitions, which completely override those from the hl-line overlay. If you define a face for the display string that only specifies a foreground color, then Emacs will use the hl-line overlay for the background color. This is normal operation of the Emacs display engine, it has been like that since Emacs 21. IOW, this is not a bug. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 14:26:42 2017 Received: (at 25348) by debbugs.gnu.org; 4 Jan 2017 19:26:42 +0000 Received: from localhost ([127.0.0.1]:41426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOrCs-0006Eg-Eq for submit@debbugs.gnu.org; Wed, 04 Jan 2017 14:26:42 -0500 Received: from mail-qt0-f196.google.com ([209.85.216.196]:34687) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOrCr-0006EU-5T for 25348@debbugs.gnu.org; Wed, 04 Jan 2017 14:26:41 -0500 Received: by mail-qt0-f196.google.com with SMTP id j29so4085499qtc.1 for <25348@debbugs.gnu.org>; Wed, 04 Jan 2017 11:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HrXC2THiaT3SznVQgviLE4id7FK/Foc+n6ZwuIxaIEA=; b=sUMyokhcPTqeuDB8TEZvsFBkLs9Rn2RpxzDuRrFaSZMIfHc6BN9zpfzt5k/f8K4NYL iCPONWH7kWgh9HB5hCVPjhM/RH57sBi4jTXqhuF3NOhYthEduayaYGxVMXD+08cRDBp5 4w9qySgaI/61ffTm7Q7v0Dc/43DQHM2jSewW9uhpHDVOVHHDReFjcgXMnbsotZIkKxQT S0njgpIKJhdP8DmXfsThaVMklOvlsGqYs6BhWQktTHOte1lokq6ExSwGmv+1D65/EcCz BG40PWjMvGPxosr8Xp/CHC8kV6iEW5b9Dt6iBwD+qzPEBwVHRG4fj5OOjY79RwXq0mbT qvIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HrXC2THiaT3SznVQgviLE4id7FK/Foc+n6ZwuIxaIEA=; b=mqgMuLlJsOEAet+bK7FBoTl6yJkzlecWbHA+cqnJwEqMQxbovy96EpLZpa0Uvl31Lz mc3z4zDJDWUveagcWJX2NDxCkKpyAEBAPE8uR1S9ImXD8Pmacm9hAVo9Sao8qkF4Mzrd gzsAt+I1WoVX2JQHm/XeKyrjwcWuFXojakxdakOE5pjBv8bIOtCjr4M94MkDJPW1f4I7 J0aNs8a31FHHkOgDd4jV0j0iiC7CxMGJCERJ0xin994jnbWQUdoKsSDImlOZtkOqky4g 4SISyKXWFgSrpEw9qYI0jYM2lFVH/Th799INJr5MPT2KC3gIQvjQqiGoVb7rV+4waf+J RpiA== X-Gm-Message-State: AIkVDXK+Yfmf2/0h3Mv4/HxyOTu6+4wS4p0g4+8arEL6RW1JOa7jzlGTVa9p6WzOA2KYiPgqUlAa6nOQcW/Wyw== X-Received: by 10.200.40.179 with SMTP id i48mr70062123qti.42.1483557995436; Wed, 04 Jan 2017 11:26:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.164 with HTTP; Wed, 4 Jan 2017 11:25:54 -0800 (PST) In-Reply-To: <83vatuernc.fsf@gnu.org> References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> <83vatuernc.fsf@gnu.org> From: Travis Foster Date: Wed, 4 Jan 2017 11:25:54 -0800 X-Google-Sender-Auth: WkY7B0e90ycG4SHOu_T7hmhABsw Message-ID: Subject: Re: bug#25348: `display` property faces are prioritized above overlays To: Eli Zaretskii , 25348@debbugs.gnu.org Content-Type: multipart/alternative; boundary=001a113f1f0c5261f2054549c3c7 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 25348 Cc: Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) --001a113f1f0c5261f2054549c3c7 Content-Type: text/plain; charset=UTF-8 > Emacs uses the face from the overlay only for text to which this > overlay is applied. The display string is therefore using its own > face definitions, which completely override those from the hl-line > overlay. I just figured that the overlay applies to a range of text, and the replacement text is within that range ... so it seems like it should be affected. I guess not, though. So what you're saying is, since the replacement text is not technically part of the buffer text, it doesn't count as being within the range of the overlay, and it isn't affected by the overlay at all? But that's not the case either, because as you also stated, face attributes from the overlay are applied to the display string, as long as the display string doesn't already specify those attributes. So, it seems that the overlay is applied to the display string, but it just takes a lower priority than the display string's text properties. If that was the design, that's fine, but it does conflict with the documentation stating that overlays always take priority over text properties. I haven't looked at the code for this, so I might be wrong, but what appears to be happening is this: 1. The overlay is applied to the buffer text, and the overlay face takes priority over the buffer text's faces 2. If the overlay had a display property, that would take priority over the buffer text's display property, but since the overlay has no such property, this doesn't happen 3. After the overlay is applied, the display property is applied, and its faces take priority over the existing faces, including those supplied by the overlay So the priority goes: display property faces > overlay faces > buffer faces. Am I on the right track? --001a113f1f0c5261f2054549c3c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Emacs uses the face from the overlay only for text to= which this
> overlay is applied.=C2=A0 The display string is therefo= re using its own
> face definitions, which completely override those = from the hl-line
> overlay.

I just figured that the overlay ap= plies to a range of text, and the replacement text is within that range ...= so it seems like it should be affected. I guess not, though. So what you&#= 39;re saying is, since the replacement text is not technically part of the = buffer text, it doesn't count as being within the range of the overlay,= and it isn't affected by the overlay at all? But that's not the ca= se either, because as you also stated, face attributes from the overlay are= applied to the display string, as long as the display string doesn't a= lready specify those attributes. So, it seems that the overlay is applied t= o the display string, but it just takes a lower priority than the display s= tring's text properties. If that was the design, that's fine, but i= t does conflict with the documentation stating that overlays always take pr= iority over text properties.

I haven't looked at the code f= or this, so I might be wrong, but what appears to be happening is this:
1. The overlay is applied to the buffer text, and the overlay face t= akes priority over the buffer text's faces
2. If the overlay = had a display property, that would take priority over the buffer text's= display property, but since the overlay has no such property, this doesn&#= 39;t happen
3. After the overlay is applied, the display property= is applied, and its faces take priority over the existing faces, including= those supplied by the overlay

So the priority goe= s: display property faces > overlay faces > buffer faces. Am I on the= right track?
--001a113f1f0c5261f2054549c3c7-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 14:56:16 2017 Received: (at 25348) by debbugs.gnu.org; 4 Jan 2017 19:56:16 +0000 Received: from localhost ([127.0.0.1]:41443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOrfT-0006xo-Oe for submit@debbugs.gnu.org; Wed, 04 Jan 2017 14:56:16 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46405) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOrfR-0006xb-IA for 25348@debbugs.gnu.org; Wed, 04 Jan 2017 14:56:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOrfL-0004z2-7s for 25348@debbugs.gnu.org; Wed, 04 Jan 2017 14:56:08 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOrfB-0004ws-Sj; Wed, 04 Jan 2017 14:55:57 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3972 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cOrf8-0000gx-Tx; Wed, 04 Jan 2017 14:55:57 -0500 Date: Wed, 04 Jan 2017 21:55:55 +0200 Message-Id: <83lguqeh10.fsf@gnu.org> From: Eli Zaretskii To: Travis Foster In-reply-to: (message from Travis Foster on Wed, 4 Jan 2017 11:25:54 -0800) Subject: Re: bug#25348: `display` property faces are prioritized above overlays References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> <83vatuernc.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-Debbugs-Envelope-To: 25348 Cc: 25348@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > From: Travis Foster > Date: Wed, 4 Jan 2017 11:25:54 -0800 > Cc: Drew Adams > > I just figured that the overlay applies to a range of text, and the replacement text is within that range ... so it > seems like it should be affected. The replacement text comes from a string, not from the buffer, so it is NOT within the range of buffer text to which the overlay is applied. > So what you're saying is, since the replacement text is > not technically part of the buffer text, it doesn't count as being within the range of the overlay, and it isn't > affected by the overlay at all? Yes. > But that's not the case either, because as you also stated, face attributes from > the overlay are applied to the display string, as long as the display string doesn't already specify those > attributes. If the face of the display string doesn't specify the background color, the only sensible thing to do is to use the background of the "underlying" buffer text. (Note that in this case the issue of priority doesn't arise either, because only one of the sources specifies the background color.) > So, it seems that the overlay is applied to the display string, but it just takes a lower priority than the > display string's text properties. That's your interpretation, but it is incorrect. As a matter of fact, the priority is not applicable in this case, because the two faces are applied to two different objects: one is buffer text, the other is the text of the display string. > it does conflict with the documentation stating that overlays always > take priority over text properties. Not in my view and interpretation, no. > I haven't looked at the code for this, so I might be wrong, but what appears to be happening is this: > 1. The overlay is applied to the buffer text, and the overlay face takes priority over the buffer text's faces > 2. If the overlay had a display property, that would take priority over the buffer text's display property, but since > the overlay has no such property, this doesn't happen > 3. After the overlay is applied, the display property is applied, and its faces take priority over the existing faces, > including those supplied by the overlay That's not how the code works, if you want to talk about the implementation. What actually happens is this: . The display engine displays the buffer text with the overlay face applied, one character at a time, until it bumps into the display string. . The display engine then stops displaying buffer text, pushes its internal state onto a stack, then starts displaying the display string, using the face of that string. If the face doesn't specify all the face attributes, it is merged with the face of the "underlying" buffer text, in this case the face of the hl-line overlay. . When the text of the display string is exhausted, the display engine pops the previous state from the stack, jumps to buffer position beyond the text replaced by the display string, and continues displaying buffer text using the overlay face. > So the priority goes: display property faces > overlay faces > buffer faces. Am I on the right track? No, because the priority is not being considered in this situation. The priority is only considered when the same text has both text properties that specify a face and one or more overlays that also specify a face. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 16:59:48 2017 Received: (at 25348) by debbugs.gnu.org; 4 Jan 2017 21:59:48 +0000 Received: from localhost ([127.0.0.1]:41526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOtb1-0003J0-Su for submit@debbugs.gnu.org; Wed, 04 Jan 2017 16:59:48 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:34476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOtb0-0003In-6k for 25348@debbugs.gnu.org; Wed, 04 Jan 2017 16:59:46 -0500 Received: by mail-qt0-f193.google.com with SMTP id a29so270048qtb.1 for <25348@debbugs.gnu.org>; Wed, 04 Jan 2017 13:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=G22tfMe1erjn9K+IR1l8e8DI4i3+gLJHROEeqBr68/w=; b=ZjqL7yHDaw3r4Qi4fo6JOkCBJKI55HL6im4XgZhhISYRp/41J2Z/RUrk2r40mMTkec XhVkesTujDwKmPcqQiZ7tqG2+6GUqZCFgzOTjUDea9PibXwuEbh6CkB6ZEMSw5qK8O5M d46GuuSa96C3VtJH8D/Q+nnE/cA8/UYn/LTcbFfdAsyGLHcUwC6vJWUtTMi+eUKultpE bnICuI5OC5kQQmC6PM81h9EfvAcA9IxBb3Zej4VMrtuIPXP2sbRsoHlnQp2GpT9IPifV hQuf637/69LhqPxIL1Y43pF3NYBCw+FF6KqUJkBvy1CJ6jnCw2TDEsjHkJb5Kt1rOX3I GFKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=G22tfMe1erjn9K+IR1l8e8DI4i3+gLJHROEeqBr68/w=; b=tmvb4/jdI2jVSv02xt5sc03lnBejVetzbtcKiAx70rYIwiMQYw3GoKADCI+nMLofjk gYKlYOkfOxwsin3uE92xDwCBgMNdAFjpqjS75CzQwqqAGQqZqnKd0g6jkDCkk6jrdv8q oI4oGyVR7cKFyw3g800nsZjg1Zr0NmMBOVagQ5PtimquMAn8w1iRPsi5X6oDY6ZDLcTO UYPT0Hcn3aBu/tgJrqXXj0XmUAZcdUoJc+ICbSAS6jcYq1B8BEkEXH1ZtYrAWHsVzv3L t5OgbNZZhitg/A3O/tAlvA/fThRECNOUGtWLf/kDRo2TGwClNDwbZ3OIdW+EdSBRaIRr XUsw== X-Gm-Message-State: AIkVDXJkcbAPV0ofxcJijclz/HhuprLgWkV7xq132LH8C/I1UCg97y52VjaEuMre5UV4JZCUAq77j1q26tXqXA== X-Received: by 10.200.34.212 with SMTP id g20mr66953940qta.243.1483567180622; Wed, 04 Jan 2017 13:59:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.164 with HTTP; Wed, 4 Jan 2017 13:59:00 -0800 (PST) In-Reply-To: <83lguqeh10.fsf@gnu.org> References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> <83vatuernc.fsf@gnu.org> <83lguqeh10.fsf@gnu.org> From: Travis Foster Date: Wed, 4 Jan 2017 13:59:00 -0800 X-Google-Sender-Auth: dyi4qGHN39oUTpz8ZJV3Um0LK08 Message-ID: Subject: Re: bug#25348: `display` property faces are prioritized above overlays To: Eli Zaretskii , 25348@debbugs.gnu.org Content-Type: multipart/alternative; boundary=001a11404adacd322305454be696 X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25348 Cc: Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --001a11404adacd322305454be696 Content-Type: text/plain; charset=UTF-8 > If the face of the display string doesn't specify the background > color, the only sensible thing to do is to use the background of the > "underlying" buffer text. (Note that in this case the issue of > priority doesn't arise either, because only one of the sources > specifies the background color.) Alright ... and the "underlying" face it appears to use is the one applied to the first character of the replacee text. That makes sense, I guess. > > So the priority goes: display property faces > overlay faces > buffer faces. Am I on the right track? > > No, because the priority is not being considered in this situation. > The priority is only considered when the same text has both text > properties that specify a face and one or more overlays that also > specify a face. Apologies, I was using 'priority' in the more general sense of "which faces will show up on the screen", rather than in the implementation sense of the overlay `priority` property and priority calculation. Perhaps I should use another word instead, like 'precedence' or something. > > it does conflict with the documentation stating that overlays always > > take priority over text properties. > > Not in my view and interpretation, no. But it appears to, I think. All I'm saying here is that, based entirely on the wording of the documentation and with no insight into the implementation, the most intuitive interpretation is that the display text property should be expanded first, and then the faces and properties from the overlay should be applied on top of that. I realize that this wouldn't quite work, since trying to apply an overlay on top of already replaced text would be problematic, but it's still surprising that the precedence for faces isn't [overlay display string > overlay text > buffer display string > buffer text]. I don't know, maybe I'm wrong. So, alright, this isn't a bug. What if I don't want this behavior, though? Is there anything I can do to my display properties so that they don't show through overlays? I sort of doubt it at this point, but I might as well ask. --001a11404adacd322305454be696 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> If the face of the display string doesn't specify= the background
> color, the only sensible thing to do is to use the = background of the
> "underlying" buffer text. =C2=A0(Note t= hat in this case the issue of
> priority doesn't arise either, be= cause only one of the sources
> specifies the background color.)
<= div>
Alright ... and the "underlying" face it appea= rs to use is the one applied to the first character of the replacee text. T= hat makes sense, I guess.

> > So the priority goes: dis= play property faces > overlay faces > buffer faces. Am I on the right= track?
>
> No, because the priority is not being considered in= this situation.
> The priority is only considered when the same text= has both text
> properties that specify a face and one or more overl= ays that also
> specify a face.

Apologies, I= was using 'priority' in the more general sense of "which face= s will show up on the screen", rather than in the implementation sense= of the overlay `priority` property and priority calculation. Perhaps I sho= uld use another word instead, like 'precedence' or something.
=

> > it does conflict with the documentation stating that ove= rlays always
> > take priority over text properties.
>
&g= t; Not in my view and interpretation, no.

But it appears = to, I think. All I'm saying here is that, based entirely on the wording= of the documentation and with no insight into the implementation, the most= intuitive interpretation is that the display text property should be expan= ded first, and then the faces and properties from the overlay should be app= lied on top of that. I realize that this wouldn't quite work, since try= ing to apply an overlay on top of already replaced text would be problemati= c, but it's still surprising that the precedence for faces isn't [o= verlay display string > overlay text > buffer display string > buf= fer text]. I don't know, maybe I'm wrong.

= So, alright, this isn't a bug. What if I don't want this behavior, = though? Is there anything I can do to my display properties so that they do= n't show through overlays? I sort of doubt it at this point, but I migh= t as well ask.
--001a11404adacd322305454be696-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 05 11:27:56 2017 Received: (at 25348) by debbugs.gnu.org; 5 Jan 2017 16:27:56 +0000 Received: from localhost ([127.0.0.1]:44010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPAtQ-0001kY-3m for submit@debbugs.gnu.org; Thu, 05 Jan 2017 11:27:56 -0500 Received: from eggs.gnu.org ([208.118.235.92]:53872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPAtN-0001kH-Rx for 25348@debbugs.gnu.org; Thu, 05 Jan 2017 11:27:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cPAtH-0000iH-NV for 25348@debbugs.gnu.org; Thu, 05 Jan 2017 11:27:48 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60952) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cPAt9-0000fJ-B6; Thu, 05 Jan 2017 11:27:39 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1054 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cPAt8-0002K8-FX; Thu, 05 Jan 2017 11:27:38 -0500 Date: Thu, 05 Jan 2017 18:27:55 +0200 Message-Id: <8337gxeak4.fsf@gnu.org> From: Eli Zaretskii To: Travis Foster In-reply-to: (message from Travis Foster on Wed, 4 Jan 2017 13:59:00 -0800) Subject: Re: bug#25348: `display` property faces are prioritized above overlays References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> <83vatuernc.fsf@gnu.org> <83lguqeh10.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-Debbugs-Envelope-To: 25348 Cc: 25348@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > From: Travis Foster > Date: Wed, 4 Jan 2017 13:59:00 -0800 > Cc: Drew Adams > > So, alright, this isn't a bug. What if I don't want this behavior, though? Is there anything I can do to my display > properties so that they don't show through overlays? I sort of doubt it at this point, but I might as well ask. As I already mentioned, if your face for the display string doesn't specify a background color, the hl-line background color will be used. If that's not an option, perhaps you could do that dynamically, by changing the face of the display string whenever the hl-line overlay is on the line where you have your display string? Or maybe someone else will have more clever ideas. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 05 13:11:20 2017 Received: (at 25348) by debbugs.gnu.org; 5 Jan 2017 18:11:20 +0000 Received: from localhost ([127.0.0.1]:44030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPCVU-0004Ov-Bu for submit@debbugs.gnu.org; Thu, 05 Jan 2017 13:11:20 -0500 Received: from mail-qk0-f194.google.com ([209.85.220.194]:33124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPCVQ-0004Od-A7 for 25348@debbugs.gnu.org; Thu, 05 Jan 2017 13:11:16 -0500 Received: by mail-qk0-f194.google.com with SMTP id n21so59567013qka.0 for <25348@debbugs.gnu.org>; Thu, 05 Jan 2017 10:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YlQD/9G1A/0Jcv2bNNyUQFZTLH42o/UjJxWwZr/7wzg=; b=dOCweGzbyNYln/PdnNmwiylwQw4ZnRrcFQBedeyXdQD+sIuWc/5jlafEL7OxASJ6Mv ZyVq+KqJCDqENHu8V7v7Og4Gt9QZX6tPhw9QfenKpmcKUIGXSmN3giMCC8pIzXRVuxB/ 3uejn8QhIPTsT9wMkQAaO09po8uOeHk6ZljmaN6cWKi7Mv/hRz85cyrPZ4jAqmcynp/O pHb2E2URaUzlX7wtNClCi3lIajZxNHUPdYyAH1CHtN4Dfuq3mZgSBZkgM3WPLAbyK67G 6y1QallH4QjI3JC9lD3MpSlmS2+Q0fij/kiDq9lRm+A0SvZiurppMyjLRa4s/IrhJKkM 2AtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YlQD/9G1A/0Jcv2bNNyUQFZTLH42o/UjJxWwZr/7wzg=; b=oiBsTBrPB8tWaO3yFjrUcJMyHtiTYqAUpVcsSRLTr9l5UyhTuWbJ60WmtUUdq6P0xg Rtpho9NXb4ArWt8pZfwLgxaADGfTZj53DvyTo5WS5+cdrwokLSbhgjb805dZ3GCcx0F7 JnKDqmRW8dq1rgCBpWYsaA8+ZRelf3lYwgrWadqgvDY5f4HxR64UDoEohF4uWTROdRT5 3K6yRiKCb7BGfodx05skLoaxjbkcJYBfGExKjot/K3bDLcebGtH41K90UNktAGLJa7Kx Jj5HR/2u7JrjQIzqzj5ET+3xcqEmZiSoWFu+zCd+tfPC9zNnLggSK+KaRuX6uoAEwBp8 edAg== X-Gm-Message-State: AIkVDXJoPPu1Qyc9mw9maJLKBAKWTQ5Bazk+Nyt3u/p3lsRFTHIYrOnEwd44osz4AhmyAC2s1/SilAl8PYWZKw== X-Received: by 10.55.142.194 with SMTP id q185mr68887979qkd.82.1483639870421; Thu, 05 Jan 2017 10:11:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.164 with HTTP; Thu, 5 Jan 2017 10:10:30 -0800 (PST) In-Reply-To: <8337gxeak4.fsf@gnu.org> References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> <83vatuernc.fsf@gnu.org> <83lguqeh10.fsf@gnu.org> <8337gxeak4.fsf@gnu.org> From: Travis Foster Date: Thu, 5 Jan 2017 10:10:30 -0800 X-Google-Sender-Auth: QjWqmfbtKI1ArHYpiWjUAE0wQWc Message-ID: Subject: Re: bug#25348: `display` property faces are prioritized above overlays To: Eli Zaretskii , 25348@debbugs.gnu.org Content-Type: multipart/alternative; boundary=94eb2c0854dc7384b905455cd3eb X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25348 Cc: Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --94eb2c0854dc7384b905455cd3eb Content-Type: text/plain; charset=UTF-8 > As I already mentioned, if your face for the display string doesn't > specify a background color, the hl-line background color will be used. Yeah, I don't think that's an option. My use case is, I'm coloring tab characters with different colors for multiple segments within the character. So to do that, I'm setting the tab's display property to a number of spaces equal to the width of the tab, and then I'm coloring the spaces separately. But, the entire point is that I'm coloring whitespace, so it has to set the background color. > If that's not an option, perhaps you could do that dynamically, by > changing the face of the display string whenever the hl-line overlay > is on the line where you have your display string? That's a possibility. I'll have to think about that. Thanks for the help. --94eb2c0854dc7384b905455cd3eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> As I already mentioned, if your face for the display = string doesn't
> specify a background color, the hl-line backgrou= nd color will be used.

Yeah, I don't think that's an option.= My use case is, I'm coloring tab characters with different colors for = multiple segments within the character. So to do that, I'm setting the = tab's display property to a number of spaces equal to the width of the = tab, and then I'm coloring the spaces separately. But, the entire point= is that I'm coloring whitespace, so it has to set the background color= .

> If that's not an option, perhaps you could do that dynami= cally, by
> changing the face of the display string whenever the hl-l= ine overlay
> is on the line where you have your display string?
=
That's a possibility. I'll have to think about that.=

Thanks for the help.
--94eb2c0854dc7384b905455cd3eb-- From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 12:22:15 2019 Received: (at 25348) by debbugs.gnu.org; 29 Sep 2019 16:22:15 +0000 Received: from localhost ([127.0.0.1]:55696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iEbxe-0007IN-Pz for submit@debbugs.gnu.org; Sun, 29 Sep 2019 12:22:14 -0400 Received: from quimby.gnus.org ([80.91.231.51]:58340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iEbxd-0007ID-3j for 25348@debbugs.gnu.org; Sun, 29 Sep 2019 12:22:13 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iEbxY-000387-Rb; Sun, 29 Sep 2019 18:22:11 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#25348: `display` property faces are prioritized above overlays References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> <83vatuernc.fsf@gnu.org> Date: Sun, 29 Sep 2019 18:22:08 +0200 In-Reply-To: <83vatuernc.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 04 Jan 2017 18:06:31 +0200") Message-ID: <878sq7dqdr.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > This is normal operation of the Emacs display engine, it has been like > that since Emacs 21. IOW, this is not a bug. I think this was the conclusion here, so I'm closing this bug report. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25348 Cc: Travis Foster , 25348@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > This is normal operation of the Emacs display engine, it has been like > that since Emacs 21. IOW, this is not a bug. I think this was the conclusion here, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 12:22:18 2019 Received: (at control) by debbugs.gnu.org; 29 Sep 2019 16:22:18 +0000 Received: from localhost ([127.0.0.1]:55699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iEbxi-0007If-0x for submit@debbugs.gnu.org; Sun, 29 Sep 2019 12:22:18 -0400 Received: from quimby.gnus.org ([80.91.231.51]:58356) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iEbxh-0007IW-2t for control@debbugs.gnu.org; Sun, 29 Sep 2019 12:22:17 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iEbxe-00038H-Ew for control@debbugs.gnu.org; Sun, 29 Sep 2019 18:22:16 +0200 Date: Sun, 29 Sep 2019 18:22:14 +0200 Message-Id: <877e5rdqdl.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #25348 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 25348 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 25348 quit From unknown Sat Jun 21 12:11:27 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 28 Oct 2019 11:24:12 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator