emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about display engine


From: Eli Zaretskii
Subject: Re: Question about display engine
Date: Wed, 28 Aug 2019 12:07:24 +0300

> Cc: address@hidden
> From: martin rudalics <address@hidden>
> Date: Wed, 28 Aug 2019 10:35:11 +0200
> 
>  > When in 3 it says "remove", what does it means? set it to x, to default or
>  > to nil?
>  >
>  > In case we don't extend, the extra space we add after the line should
>  > have the default, face or the last in the line??
> 
> The term "remove" was meant wrt the current face used by the iterator.
> If, for example, the current face of the iterator is the one specified
> by the region face, then it probably specifies some background used
> for "normal" text.  When the display engine arrives at the newline
> character it checks whether the current face has the extend_background
> bit set and either reuses an existing or realizes a new face based on
> the background of the current face and that bit.

I think we should simply not merge the background color of the region
face when its extend bit is reset.  Then the merged face will not have
that background color.

> What realizing has to do when extend_background is false is not
> entirely clear to me either.  Suppose we have a newline character that
> is contained both in the region and a multiline comment and the region
> face results in an extend_background false bit while the comment face
> results in an extend_background true bit for the corresponding
> realized faces.
> 
> Conceptually, this means that the spaces at the end of the line should
> have the comment background but unless we expand the extend_background
> bits into full pointers to other realized faces (and have face merging
> set up these pointers and the display engine resolve them) I see no
> way how this could be realized.  So the rest of the line would be
> shown with the default face's background instead (or do whatever we do
> now when we don't expand) which obviously won't look good.

I don't see a problem here.  A user who doesn't want the region face's
background extend to the end of line wants only text (as opposed to
whitespace after the newline) to have the region's background, and
that's true both to regions that cross line boundaries and regions that
end at a newline.

> Maybe the display engine could consult, with the stop position
> privilege triggered by the newline character in mind, whether the
> extend_background false setting of the current face could result in
> applying another, lower-priority face specified by font-locking and
> consult the extend_background bit of the corresponding realized face.

I don't think I understand this proposal.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]