all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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 --]

  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.