bug#38563: closed (27.0.50; Company popup renders with newlines (?) inheriting the bg properties of the character at next line's bol)

[GNU bug Tracking System]

Your message dated Sat, 21 Dec 2019 15:22:46 +0200
with message-id <address@hidden>
and subject line Re: bug#38563: 27.0.50; Company popup renders with newlines 
(?) inheriting the bg properties of the character at next line's bol
has caused the debbugs.gnu.org bug report #38563,
regarding 27.0.50; Company popup renders with newlines (?) inheriting the bg 
properties of the character at next line's bol
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
38563: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38563
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: 27.0.50; Company popup renders with newlines (?) inheriting the bg properties of the character at next line's bol Date: Wed, 11 Dec 2019 03:13:59 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

Here's an unfortunate new behavior which I didn't have time to report
or properly describe before.

When the next line starts on a character that has a distinct background,
that background is inherited when displaying newlines inside the display
string that renders the popup.

Here are two ways I usually trigger it:

1. Initiate completion on the "Author:" line of a LogEdit buffer (the
next line is an inverse-video line).

2. Have at least one space at the beginning of a line, and have
whitespace-mode on to highlight it in red. Then initiate completion on
the preceding line.

Screenshots are attached.

Needless to say, the latest Emacs 26 doesn't exhibit this problem.

Screenshot from 2019-12-11 03-00-35.png
Description: PNG image

Screenshot from 2019-12-11 03-00-41.png
Description: PNG image

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#38563: 27.0.50; Company popup renders with newlines (?) inheriting the bg properties of the character at next line's bol
>
>
>
>
> Date: 
>
> Sat, 21 Dec 2019 15:22:46 +0200
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
>
>
>
>
> On 21.12.2019 9:53, Eli Zaretskii wrote:
>
> > Yes, this looks like a good solution to me.
>
> Thank you for verifying. Then I'm closing this report.
>
> > In fact, I was about to
> > ask you to make a similar (less elegant) change,
>
> Like temporarily changing the face of the underlying character? Yeah, I 
> would have paused at that idea.
>
> > because I couldn't
> > think of a way to resolve this in core: when a face explicitly asks to
> > extend itself past EOL, we cannot in good faith refrain from doing so
> > in some use cases.
>
> Let's see if other third-party issues come up, then.
>
>
> --- End Message ---