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

[Eli Zaretskii]

> Cc: 38563@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 13 Dec 2019 00:13:37 +0200
> 
> On 12.12.2019 13:32, Eli Zaretskii wrote:
> > The "character at next bol" sounds strange, since the display engine
> > has no look-ahead -- it never examines characters on the next line
> > while displaying the current line.  But it all starts making sense
> > when you recall that Company mode puts its overlay on that next line.
> > So the "inherited" face is not on the next line, it is at the position
> > where the Company overlay is set.  IOW, it's the "underlying face" for
> > the overlay string.
> 
> Yeah, OK. Now that you mentioned the 'default' face, I remembered: it's 
> used there exactly so that we don't inherit the background from the 
> "underlying face".

That's no longer "good enough", see below.

> > Should be fixed now, please test.
> 
> It looks fixed in the whitespace-mode example, but not in the other one.
> 
> Just call M-x company-complete-common on the "Author:" line in a LogEdit 
> buffer to reproduce. (I've tested common d7efe98951).

That's not a bug: the face on that thin line on whose first character
you put the tooltip overlay has a non-nil :extend attribute, so
Company will have to explicitly say ':extend nil' in its face(s) to
countermand that.  Recall that a string from a display property merges
into its face all the attributes from the "underlying" face, so with
the current :extend machinery it is no longer enough just to specify a
background color in the display string's face, as you did before.

Btw, if you used 'default instead of '(default), I think that would
have avoided the issue as well, because the default face gets a
special treatment in this context.

> By the way, I kind of wonder why the fix added more lines than it 
> deleted.

??? I added a condition under which not to merge a face, so how can I
avoid adding a few lines?  The addition is 7 lines of code, including
a small refactoring, all the rest is comments.

> Before, this feature just worked. Was that simply by accident? 
> Or were the changes brought in by :extend major enough?

Previously, whether a face's background was extended to EOL was
determined only by the background color of the newline; now the
:extend attribute determines that independently of the background
color.