From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25348: `display` property faces are prioritized above overlays Date: Wed, 04 Jan 2017 21:55:55 +0200 Message-ID: <83lguqeh10.fsf@gnu.org> References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> <83vatuernc.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1483559841 30778 195.159.176.226 (4 Jan 2017 19:57:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2017 19:57:21 +0000 (UTC) Cc: 25348@debbugs.gnu.org To: Travis Foster Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 04 20:57: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 1cOrgK-0006ii-Mp for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jan 2017 20:57:08 +0100 Original-Received: from localhost ([::1]:41232 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOrgO-0005G1-Jt for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jan 2017 14:57:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOrgI-0005Eu-EJ for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 14:57:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOrgE-0005SQ-5J for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 14:57:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54278) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cOrgE-0005S7-2R for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 14:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cOrgD-0006yx-LJ for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 14:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Jan 2017 19:57: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.148355977626777 (code B ref 25348); Wed, 04 Jan 2017 19:57:01 +0000 Original-Received: (at 25348) by debbugs.gnu.org; 4 Jan 2017 19:56:16 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 In-reply-to: (message from Travis Foster on Wed, 4 Jan 2017 11:25:54 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:127753 Archived-At: > 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.