bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#38563: 27.0.50; Company popup renders with newlines (?) inheriting t


From: Dmitry Gutov
Subject: bug#38563: 27.0.50; Company popup renders with newlines (?) inheriting the bg properties of the character at next line's bol
Date: Fri, 13 Dec 2019 12:17:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 13.12.2019 10:22, Eli Zaretskii wrote:

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.

I see. But isn't the issue that the background from the underlying face is used at all, rather that it's extended?

But I suppose I could add a face with ':extend nil' and use it in place of 'default' there.

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.

I can bump the requirement to Emacs 24.4 and use add-face-text-property there (too bad for setting mouse-face only the slower function is available), but as you noted in the follow-up email, it doesn't help with the remaining example.

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.

If the issue is "whether to extend", then indeed, it makes sense, thanks.

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.

...but the background color is taken specifically from the face that specified :extend?





reply via email to

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