From: Eli Zaretskii <eliz@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 1222@debbugs.gnu.org
Subject: bug#1222: overlay display inherits face properties from buffer
Date: Mon, 30 Sep 2019 10:44:50 +0300 [thread overview]
Message-ID: <83zhimcjnx.fsf@gnu.org> (raw)
In-Reply-To: <87a7amjmiu.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 30 Sep 2019 09:01:13 +0200)
tags 1222 notabug
thanks
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 30 Sep 2019 09:01:13 +0200
> Cc: 1222@debbugs.gnu.org
>
> Glenn Morris <rgm@gnu.org> writes:
>
> > This issue also affects before- and after-strings, albeit in slightly
> > different ways:
> >
> > Example:
> >
> > (let ((buff (generate-new-buffer "overlay test"))
> > o)
> > (with-current-buffer buff
> > (insert (propertize "text" 'face '(:background "red")))
> > (setq o (make-overlay (point-min) (point-max)))
> > (overlay-put o 'display "display")
> > (overlay-put o 'before-string "before-string")
> > (overlay-put o 'after-string "after-string")
> > (insert (propertize "more" 'face '(:background "green")))
> > (pop-to-buffer buff)))
> >
> > "before-string" and "display" have a red background, "after-string"
> > has a green background.
> >
> > Ideally, face properties should not be inherited from the buffer in
> > this way.
>
> Hm... is this the same as bug#25348? If so, it was decided there that
> this was behaviour as designed, I think.
No, it isn't related to bug#25348. But it's "as designed"
nonetheless: the display engine always merges all the sources of the
face information relevant to the current buffer position. This is
documented in the ELisp manual, see the beginning of the node
"Displaying Faces" (I believe this wasn't documented at the time this
bug was filed).
IOW, what is reported here is the expected behavior, that's how the
code was designed and implemented.
P.S. The original report says "inherits face properties from the
following buffer text", but the "following" part is only accurate when
referring to how text appears on display. The Lisp code in the report
clearly puts the red background on the text "covered" by the overlay,
so that background affects the buffer position(s) where the overlay is
set up.
prev parent reply other threads:[~2019-09-30 7:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1wbpxd5ta5.fsf@fencepost.gnu.org>
2019-09-30 7:01 ` bug#1222: overlay display inherits face properties from buffer Lars Ingebrigtsen
2019-09-30 7:44 ` Eli Zaretskii [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83zhimcjnx.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=1222@debbugs.gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.