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

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

bug#42552: closed (28.0.50; Overlay 'face' property doesn't set the "und


From: GNU bug Tracking System
Subject: bug#42552: closed (28.0.50; Overlay 'face' property doesn't set the "underlying face" for 'after-string')
Date: Mon, 10 Aug 2020 22:29:01 +0000

Your message dated Tue, 11 Aug 2020 01:27:59 +0300
with message-id <2b1fda37-b193-0119-3fab-71181fc758ae@yandex.ru>
and subject line Re: bug#42552: 28.0.50; Overlay 'face' property doesn't set 
the "underlying face" for 'after-string'
has caused the debbugs.gnu.org bug report #42552,
regarding 28.0.50; Overlay 'face' property doesn't set the "underlying face" 
for 'after-string'
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
42552: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=42552
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 28.0.50; Overlay 'face' property doesn't set the "underlying face" for 'after-string' Date: Sun, 26 Jul 2020 21:23:32 +0300 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 I have tried to find a workaround around bug#42521 to render a completion popup with images.

The attached patch almost works, except in Emacs 27+ it leads to a
repeat of bug#38563. Meaning, the rendered popup inherits certain
properties (most importantly, :extend) from the character under the end
of the overlay. Leading to similar visual effects, screenshots attached.

I would hope to solve it like we solved it in bug#38563, but the 'face'
overlay property doesn't seem to have any effect here.

The attached patch for company.el should apply cleanly on top of its
current code in ELPA.

The reproduction scenario is almost the same, only in this case the problem occurs when the *end* of the overlay falls on a position with
the non-nil 'extend' property (and the overlay is 10 lines long).
See the screenshots.

Please let me know if you need any further clarifications.

I do believe it's a regression, considering the same code works okay in
Emacs 26.3, in exact same situations (whitespace-mode 'tail' face or the
log-edit line under the end of the popup overlay).

In GNU Emacs 28.0.50 (build 25, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2020-07-20 built on potemkin
Repository revision: 4c08c2f45b9bb0265f6d7c3529011dee1b18e843
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Ubuntu 20.04.1 LTS

Attachment: company.el.diff
Description: Text Data

Attachment: Screenshot from 2020-07-26 20-58-50.png
Description: PNG image

Attachment: Screenshot from 2020-07-26 20-59-25.png
Description: PNG image


--- End Message ---
--- Begin Message --- Subject: Re: bug#42552: 28.0.50; Overlay 'face' property doesn't set the "underlying face" for 'after-string' Date: Tue, 11 Aug 2020 01:27:59 +0300 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
On 07.08.2020 08:42, Eli Zaretskii wrote:

1. Eval:

(with-silent-modifications
    (insert (propertize "abc"
                        'font-lock-face
                        '((:background "green" :extend t)
                          default
                          ( :inverse-video t
                            :foreground "yellow"
                            :extend t)))))

2. C-j

The "extended" newline is yellow.

That's expected due to face-merging, no?

I would have expected it to be green, at least. But if you say it's working correctly, it probably is.

I'll try to implement this all as suggested, and will come back after.

Should we close this bug or keep it open?

I've pushed the changes based on this discussion, so the matter looks closed.

Thanks.


--- End Message ---

reply via email to

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