From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: :extend t inheritance Date: Sat, 26 Oct 2019 23:13:40 +0000 (UTC) Message-ID: <453335474.949467.1572131620451@mail.yahoo.com> References: <87zhhrmcaq.fsf@kenko.localhost.com> <83o8y6xnmn.fsf@gnu.org> <20191026014911.7riwc5oq6epjhdiq@Ergus> <8336fgvuby.fsf@gnu.org> <357181555.902089.1572117701015@mail.yahoo.com> <83ftjfthnj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_949466_2147285101.1572131620450" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="147729"; mail-complaints-to="usenet@blaine.gmane.org" Cc: ingo.lohmar@posteo.net, emacs-devel@gnu.org To: eliz@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 27 01:13:57 2019 Return-path: Envelope-to: ged-emacs-devel@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 1iOVFt-000cGl-0i for ged-emacs-devel@m.gmane.org; Sun, 27 Oct 2019 01:13:57 +0200 Original-Received: from localhost ([::1]:43444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOVFr-0003gU-R4 for ged-emacs-devel@m.gmane.org; Sat, 26 Oct 2019 19:13:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40598) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOVFj-0003YZ-F1 for emacs-devel@gnu.org; Sat, 26 Oct 2019 19:13:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOVFh-0007rN-9M for emacs-devel@gnu.org; Sat, 26 Oct 2019 19:13:46 -0400 Original-Received: from sonic301-3.consmr.mail.bf2.yahoo.com ([74.6.129.42]:43557) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iOVFg-0007r7-S6 for emacs-devel@gnu.org; Sat, 26 Oct 2019 19:13:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1572131623; bh=4zdU49jWMMWdGXWSW66r4V6DvWHnrMqvkDlDK13J1os=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=o7yglxSDtNCf1T06imX1j7Qd0u2utTIci2qDbz4wlbRYMF9Peh7EsabOmWTz/CEL7Fa1hcPiuN+SR6WrM7DsXNCskSGTmUsCLhOaayqorgeuMUmm1Xeml6Ydtv8yNjADnwbtJ3jxgMWGicAX+sZKOVm8tc+PXvwhYovPx+5q/wX1+n/CRxCrmKfw1tsyibJbZFOT90NxoQ6SvsDyDx4vEUPbGdc+6Q/L5sEU89qdXPIcAp/6uOL9vUwJTM9Jk3t9TofdPEhLmc07iUYFdB1IUxSPZXd2TQmOqvhV3UkIAebFMzvR/aldKNYkMPXKha89kxEiiB0b+Y4z43c6OQVAAQ== X-YMail-OSG: 2pCgHZUVM1lp4XH2pdm7rw_.EDUSCAS77q.i9ZA0d.nfUD1EncOpRk_KFA1PzpV vgvpwz.5EEGab5rtnNAii3X1d4TPakpR4y62Vr32SSmFb7qL6JZ5x9BNuCBUzjPgq3E7_yOKiaKz z2Jyb2Q.L5PnSUL6OzY2_OON6ekFSMOJJkmLfJQxb_sds5i2U1AnWD04lvF11tC8e18r8sRTGABc bT35ENAvsGOXh8pXCRfTl_mS6fMvzbP9Dx21CXfsoGpTaX1xCFg66FOPUP_2cUqcqDKcGPPwOzL. 6OnzjEYMPgpd0NgcQbpYSA10F_I8VK3C5kvW_K.pIVnXVF9a0WbAVrcF241fhd1uNUyGyydzPrLw DT2pYApaNgd.MeqbJYopzosbnx1K16tFmJkt2GLTkAaKHZU0kHob68bhg.oc4MEyhgcK0p01p6Ld p0Brjbwtp0iszM16yWk_R5.MO1UwtDw2_MSmPFNkEBebGxptA5Y3KiFptKrCj6xGIcjMwTo40rIY T3CcuTtUvjvFhGJ4mWa9NgeVzg1uFrS3cs_LXlkAhWAgSCOIpqPD2pS._5DJGGNKo2171WqxYGXe rtmmrcRJ3u7EHXW7xOvv1..agQgq2yw_siSvB.PpC22LRfOOaSYf9VhWMGd48vvCpz2sGbBJfdAE XJhZuRAQhVgxrSoKlU0D0_iSUc3qlTxjhi1drTxMk9yHNxrICHg54DrYcE.HAENu3UoNIFPiZY0J rf32mnZAHu9jRsMSvZzIGsqCTVONG6VS6GW7D.tJqhBqi0dcMPm_QT0Q091tyRWbmMQBvl5zo1ce qHyvf4wWhTGBQFYpF1qcvgG6.tKlDTCRg0trPj7_1f Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Sat, 26 Oct 2019 23:13:43 +0000 In-Reply-To: <83ftjfthnj.fsf@gnu.org> X-Mailer: WebService/1.1.14593 aolwebmail Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.129.42 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:241491 Archived-At: ------=_Part_949466_2147285101.1572131620450 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 filtere= d 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 backg= round colorbecause the X display engine always do that. But, for example, u= nderlinewas not extended.This commit fixes just that. stretch_ascent was mo= ved 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 an= d 2) todescribe the situation of the glyphs color extension (mention inprev= ious paragraph) that we don't need to work around anymore becausethe glyph = fills the entire screen now..=20 =20 -----Original Message----- From: Eli Zaretskii To: Ergus Cc: ingo.lohmar ; emacs-devel 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 > Cc: emacs-devel@gnu.org, ingo.lohmar@posteo.net >=20 > Before `merge_named_face` filtered the call to `merge_face_vectors` if th= e filter parameter (lets say :extend > in our case) was `nil` or `undefined`. That was how the attr_filter worke= d.=20 >=20 > 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`.=20 >=20 > 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 pr= oblem is that the merge with the > parent faces was always made writing the TO vector (in place) as it was n= ot conditional, but we don't know in > advance if the parent (or the grand-parents) define the filter attribute = to non-nil=20 >=20 > 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, th= en I copy it into TO and continue with the > merge.=20 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).=C2=A0 Those other things is what I was asking about.=C2=A0 Just do =C2=A0 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(?).=C2=A0 What is this stuff, and what does it solve? Thanks. ------=_Part_949466_2147285101.1572131620450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ohh right, that's the other commit. When fixing this issue I found another error I didn't see in tui. After EOL we need to fill with the merged filtered face. To do that we need to add a stretch glyph; but we were just adding a normal glyph with a ' ' so the face was not really extended, just the background color because the X display engine always do that. But, for example, underline was not extended. This commit fixes just that. stretch_ascent was moved out of the if(column_indicator) because the new stretch_glyphs needs it any way and the two comments were 1) for old moved code not there anymore and 2) to describe the situation of the glyphs color extension (mention in previous paragraph) that we don't need to work around anymore because the 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 <spac= ibba@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 wo= rked.
>
> But in this case it i= s actually wrong when the face was inherited and the attribute was `undefin= ed` because
> maybe the `parent` face define the filte= r parameter to `non-nil`.
>
> S= o now `merge_named_face` calls `merge_face_vectors` if the parameter is und= efined too, and
> `merge_face_vectors` internally cond= itions if the merge is needed. The problem is that the merge with the
> parent faces was always made writing the TO vector (in pl= ace) as it was not conditional, but we don't know in
>= advance if the parent (or the grand-parents) define the filter attribute t= o non-nil
>
> So what I did in = the `undefined` case was to make a copy of the TO vector (tmp) and merge_re= f there instead
> of for TO, after the merge I check i= f 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 coup= le
of other bugs as well).  Those other things is wh= at I was asking
about.  Just do
  git diff ...origin/fix/inherit_extend_face

in the master branch, and you will see those o= ther changes right away.
For example, I see 2 comments de= leted, and something about
stretch_ascent(?).  What = is this stuff, and what does it solve?


Thanks.

------=_Part_949466_2147285101.1572131620450--