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 13:59:00 -0800 Message-ID: References: <3385c032-ead0-4890-8cf4-e54375ea8ac7@default> <83vatuernc.fsf@gnu.org> <83lguqeh10.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11404adacd322305454be696 X-Trace: blaine.gmane.org 1483567228 490 195.159.176.226 (4 Jan 2017 22:00:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2017 22:00:28 +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 23:00:24 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 1cOtbV-0006zZ-64 for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jan 2017 23:00:17 +0100 Original-Received: from localhost ([::1]:42406 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOtbW-0000rV-AX for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jan 2017 17:00:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOtbL-0000n2-I4 for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 17:00:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOtbH-0005k3-Fl for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 17:00:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54360) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cOtbH-0005jp-Cv for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 17:00:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cOtbH-0003K0-4v for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2017 17:00:03 -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 22:00:03 +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.148356718812714 (code B ref 25348); Wed, 04 Jan 2017 22:00:03 +0000 Original-Received: (at 25348) by debbugs.gnu.org; 4 Jan 2017 21:59:48 +0000 Original-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 Original-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 Original-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) Original-Received: by 10.140.97.164 with HTTP; Wed, 4 Jan 2017 13:59:00 -0800 (PST) In-Reply-To: <83lguqeh10.fsf@gnu.org> X-Google-Sender-Auth: dyi4qGHN39oUTpz8ZJV3Um0LK08 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:127761 Archived-At: --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--