From: Ergus <spacibba@aol.com>
To: eliz@gnu.org
Cc: ingo.lohmar@posteo.net, emacs-devel@gnu.org
Subject: Re: :extend t inheritance
Date: Sat, 26 Oct 2019 23:13:40 +0000 (UTC) [thread overview]
Message-ID: <453335474.949467.1572131620451@mail.yahoo.com> (raw)
In-Reply-To: <83ftjfthnj.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
Ohh right, that's the other commit. When fixing this issue I foundanother error I didn't see in tui.After EOL we need to fill with the merged filtered face. To do that weneed to add a stretch glyph; but we were just adding a normal glyph witha ' ' so the face was not really extended, just the background colorbecause the X display engine always do that. But, for example, underlinewas not extended.This commit fixes just that. stretch_ascent was moved out of theif(column_indicator) because the new stretch_glyphs needs it any way andthe two comments were 1) for old moved code not there anymore and 2) todescribe the situation of the glyphs color extension (mention inprevious paragraph) that we don't need to work around anymore becausethe glyph fills the entire screen now..
-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org>
To: Ergus <spacibba@aol.com>
Cc: ingo.lohmar <ingo.lohmar@posteo.net>; emacs-devel <emacs-devel@gnu.org>
Sent: Sat, Oct 26, 2019 9:47 pm
Subject: Re: :extend t inheritance
> Date: Sat, 26 Oct 2019 19:21:40 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org, ingo.lohmar@posteo.net
>
> Before `merge_named_face` filtered the call to `merge_face_vectors` if the filter parameter (lets say :extend
> in our case) was `nil` or `undefined`. That was how the attr_filter worked.
>
> But in this case it is actually wrong when the face was inherited and the attribute was `undefined` because
> maybe the `parent` face define the filter parameter to `non-nil`.
>
> So now `merge_named_face` calls `merge_face_vectors` if the parameter is undefined too, and
> `merge_face_vectors` internally conditions if the merge is needed. The problem is that the merge with the
> parent faces was always made writing the TO vector (in place) as it was not conditional, but we don't know in
> advance if the parent (or the grand-parents) define the filter attribute to non-nil
>
> So what I did in the `undefined` case was to make a copy of the TO vector (tmp) and merge_ref there instead
> of for TO, after the merge I check if the attribute is set, and if so, then I copy it into TO and continue with the
> merge.
I understood all that, but the changes include more than what you
described (and your original message even said that you fixed a couple
of other bugs as well). Those other things is what I was asking
about. Just do
git diff ...origin/fix/inherit_extend_face
in the master branch, and you will see those other changes right away.
For example, I see 2 comments deleted, and something about
stretch_ascent(?). What is this stuff, and what does it solve?
Thanks.
[-- Attachment #2: Type: text/html, Size: 4015 bytes --]
next prev parent reply other threads:[~2019-10-26 23:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 20:34 :extend t inheritance Ingo Lohmar
2019-10-24 13:46 ` Eli Zaretskii
2019-10-24 15:38 ` Kévin Le Gouguec
2019-10-24 17:39 ` Ingo Lohmar
2019-10-24 22:22 ` Ergus
2019-10-26 1:49 ` Ergus
2019-10-26 7:28 ` Eli Zaretskii
2019-10-26 19:21 ` Ergus
2019-10-26 19:45 ` Eli Zaretskii
2019-10-26 23:13 ` Ergus [this message]
2019-10-27 5:51 ` Eli Zaretskii
2019-10-27 11:01 ` Ergus
2019-10-29 14:27 ` Eli Zaretskii
2019-10-28 21:24 ` Ergus
2019-10-29 3:28 ` Eli Zaretskii
2019-10-26 8:55 ` Ingo Lohmar
2019-10-26 11:41 ` Ergus
2019-10-26 11:49 ` Ingo Lohmar
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=453335474.949467.1572131620451@mail.yahoo.com \
--to=spacibba@aol.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=ingo.lohmar@posteo.net \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.