From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Travis Foster Newsgroups: gmane.emacs.bugs Subject: bug#25348: `display` property faces are prioritized above overlays Date: Wed, 4 Jan 2017 11:25:54 -0800 Message-ID: References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> <83vatuernc.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113f1f0c5261f2054549c3c7 X-Trace: blaine.gmane.org 1483558046 14324 195.159.176.226 (4 Jan 2017 19:27:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2017 19:27:26 +0000 (UTC) To: Eli Zaretskii , 25348@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 04 20:27:17 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOrDI-0001aX-U2 for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jan 2017 20:27:09 +0100 Original-Received: from localhost ([::1]:41100 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOrDL-0005Xj-Pi for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jan 2017 14:27:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOrDF-0005XU-3m for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 14:27:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOrDC-0001Sv-0c for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 14:27:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54260) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cOrDB-0001SV-TG for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 14:27:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cOrDB-0006FJ-Jo for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 14:27:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Travis Foster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Jan 2017 19:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25348 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25348-submit@debbugs.gnu.org id=B25348.148355800223978 (code B ref 25348); Wed, 04 Jan 2017 19:27:01 +0000 Original-Received: (at 25348) by debbugs.gnu.org; 4 Jan 2017 19:26:42 +0000 Original-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 Original-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 Original-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) Original-Received: by 10.140.97.164 with HTTP; Wed, 4 Jan 2017 11:25:54 -0800 (PST) In-Reply-To: <83vatuernc.fsf@gnu.org> X-Google-Sender-Auth: WkY7B0e90ycG4SHOu_T7hmhABsw X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127750 Archived-At: --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--