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

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Wed, 11 Dec 2019 01:15:02 UTC

Severity: normal

Found in version 27.0.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 38563 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38563 <at> debbugs.gnu.org
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: 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".

> 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).

By the way, I kind of wonder why the fix added more lines than it 
deleted. Before, this feature just worked. Was that simply by accident? 
Or were the changes brought in by :extend major enough?

> Btw, the bug is triggered because Company mode uses a weird '(default)
> face, a list, instead of just 'default.  This is valid, but it wastes
> a slot in the frame's face cache, so perhaps there's a good reason to
> avoid that and simplify '(default) to 'default when you propertize the
> tooltip text.

Ultimately, the reason it's there like that is because 
font-lock-append-text-property coerces all values to lists. We could 
change that and maybe save some memory in the process. It would be an 
(minor) incompatible change, however.




This bug report was last modified 5 years and 150 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.