From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38563: 27.0.50; Company popup renders with newlines (?) inheriting the bg properties of the character at next line's bol Date: Sat, 14 Dec 2019 10:13:55 +0200 Message-ID: <83fthn729o.fsf@gnu.org> References: <4c2a9d55-57d1-4c19-fe20-4ccf61d20d68@yandex.ru> <83o8weaiem.fsf@gnu.org> <4220b126-0511-d6ee-521d-d79f463ab6ee@yandex.ru> <8336dpaiee.fsf@gnu.org> <2203b03e-5558-1fe1-788a-4006602626f2@yandex.ru> <83h8248wio.fsf@gnu.org> <83wob071sd.fsf@gnu.org> <0e27fa9b-67ac-c4b4-176f-f98c151d9b19@yandex.ru> <83pngs6y1t.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="38604"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38563@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 14 09:15:14 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ig2a0-0009lc-LQ for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Dec 2019 09:15:12 +0100 Original-Received: from localhost ([::1]:57170 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ig2Zy-0006mn-SY for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Dec 2019 03:15:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52233) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ig2Zs-0006mf-02 for bug-gnu-emacs@gnu.org; Sat, 14 Dec 2019 03:15:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ig2Zq-0004su-Ke for bug-gnu-emacs@gnu.org; Sat, 14 Dec 2019 03:15:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57191) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ig2Zq-0004rZ-GR for bug-gnu-emacs@gnu.org; Sat, 14 Dec 2019 03:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ig2Zq-0007uB-Aj for bug-gnu-emacs@gnu.org; Sat, 14 Dec 2019 03:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Dec 2019 08:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38563 X-GNU-PR-Package: emacs Original-Received: via spool by 38563-submit@debbugs.gnu.org id=B38563.157631125430302 (code B ref 38563); Sat, 14 Dec 2019 08:15:02 +0000 Original-Received: (at 38563) by debbugs.gnu.org; 14 Dec 2019 08:14:14 +0000 Original-Received: from localhost ([127.0.0.1]:34931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ig2Z3-0007sf-Jp for submit@debbugs.gnu.org; Sat, 14 Dec 2019 03:14:13 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52131) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ig2Z1-0007sS-Ss for 38563@debbugs.gnu.org; Sat, 14 Dec 2019 03:14:12 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ig2Yw-0002CJ-JD; Sat, 14 Dec 2019 03:14:06 -0500 Original-Received: from [176.228.60.248] (port=1350 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ig2Yv-0008LE-Sg; Sat, 14 Dec 2019 03:14:06 -0500 In-reply-to: (message from Dmitry Gutov on Sat, 14 Dec 2019 01:10:13 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:173308 Archived-At: > Cc: 38563@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 14 Dec 2019 01:10:13 +0200 > > On 13.12.2019 17:32, Eli Zaretskii wrote: > > > ':extend nil' is "used" during merging in the sense that such a face > > is skipped when we want a face for extending past EOL. How else could > > we implement that? Setting :extend to nil means that _none_ of the > > other attributes of the face are to be taken into account for merging. > > We are talking about "merging" a list of faces applied to a 'face' text > property on a char, right? That kind of merging? We are talking about face merging for displaying a character, yes. That process merges face information from all the sources that are in effect for that character. See the description at the beginning of the "Displaying Faces" node in the ELisp manual. When we merge faces for display past EOL, we modify the face-merging process such that faces whose :extend attribute is not t are not merged. "Not merged" means here that these faces are bypassed by the merging process, so their attributes (not just the background color) do not contribute anything to the result of the merge. > If so, I would expect seeing ':extend nil' would mean not using any of > the face attributes on that char for extending past EOL. Indeed, but only for the face whose :extend is not t. Other faces do contribute the attributes to the merge. > If it's the last character on the line, using the default face's > attributes instead. Why default? There could be several faces involved (e.g., some font-lock face, plus region, plus the face from the overlay string at that position). Any of these faces whose :extend is t will get merged for character past EOL, the rest of the faces will not. > And if we see ':extend t', then we would use the background from the > first face in the list that has the :background attribute set. Is that > not how merging faces in a list value usually works? No. The :extend attribute affects only the face where that attribute is set. It doesn't affect other faces, and also it affects all the attributes, not just the background color. > > Inheritance just makes the inheriting face implicitly behave as if its > > :extend attribute is the same as of the parent face, when the > > inheriting face doesn't itself specify :extend, i.e. has it set to > > 'unspecified'. > > I think that's how inheritance for most attributes works, right? Yes.