unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 38563@debbugs.gnu.org
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 01:10:13 +0200	[thread overview]
Message-ID: <caefd56b-aa7d-09c1-2c82-07f6961fd453@yandex.ru> (raw)
In-Reply-To: <83pngs6y1t.fsf@gnu.org>

On 13.12.2019 17:32, Eli Zaretskii wrote:

>>> It wouldn't have worked, because ':extend nil' means the face which
>>> says this is ineligible for face merging when face extension is
>>> considered.  IOW, ':extend nil' cannot countermand some other face
>>> that's being merged which says ':extend t'.
>>
>> Hmm, that's counter to my intuition how this should work (meaning,
>> :extend nil should be used during merging, like it's used during
>> inheritance), but maybe this way enables functionality that wouldn't be
>> possible otherwise.
> 
> ':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?

If so, I would expect seeing ':extend nil' would mean not using any of 
the face attributes on that char for extending past EOL. If it's the 
last character on the line, using the default face's attributes instead.

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?

> 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?





  reply	other threads:[~2019-12-13 23:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11  1:13 bug#38563: 27.0.50; Company popup renders with newlines (?) inheriting the bg properties of the character at next line's bol Dmitry Gutov
2019-12-11 17:20 ` Eli Zaretskii
2019-12-11 21:47   ` Dmitry Gutov
2019-12-12 11:32     ` Eli Zaretskii
2019-12-12 22:13       ` Dmitry Gutov
2019-12-13  8:22         ` Eli Zaretskii
2019-12-13  9:30           ` Eli Zaretskii
2019-12-13 10:31             ` Eli Zaretskii
2019-12-13 12:00               ` Dmitry Gutov
2019-12-13 10:17           ` Dmitry Gutov
2019-12-13 14:12             ` Eli Zaretskii
2019-12-13 15:04               ` Dmitry Gutov
2019-12-13 15:32                 ` Eli Zaretskii
2019-12-13 23:10                   ` Dmitry Gutov [this message]
2019-12-14  8:13                     ` Eli Zaretskii
2019-12-15 22:26                       ` Dmitry Gutov
2019-12-16 15:49                         ` Eli Zaretskii
2019-12-18 20:37                           ` Dmitry Gutov
2019-12-21  7:53                             ` Eli Zaretskii
2019-12-21 13:22                               ` Dmitry Gutov
2019-12-21 13:31                                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=caefd56b-aa7d-09c1-2c82-07f6961fd453@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=38563@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).