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: Question about display engine Date: Fri, 6 Sep 2019 12:30:23 +0200 Message-ID: <20190906103023.3r7aa5spkie3cca6@Ergus> References: <318675867.1913640.1567711569517.ref@mail.yahoo.com> <318675867.1913640.1567711569517@mail.yahoo.com> <8336h97qiw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="75922"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 06 12:31:54 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 1i6BWz-000Je5-Rc for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 12:31:54 +0200 Original-Received: from localhost ([::1]:54298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6BWy-0000uw-Fg for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 06:31:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50017) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6BVp-0000qN-57 for emacs-devel@gnu.org; Fri, 06 Sep 2019 06:30:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i6BVl-00022l-Cr for emacs-devel@gnu.org; Fri, 06 Sep 2019 06:30:39 -0400 Original-Received: from sonic303-20.consmr.mail.ir2.yahoo.com ([77.238.178.201]:36653) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i6BVk-00021o-Q3 for emacs-devel@gnu.org; Fri, 06 Sep 2019 06:30:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1567765835; bh=FjsSI0+yYxWQ0XCntj+0R1u/maSXv3psJGTjGCn8eEw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=PtSNe8dENPtOR/nTpof5El5er/U5k1an5SS0Z+xgw1RmFIOfikyn/tb5t3S2O/vVi5FdJF4OVhJ0CZk8vT4vDJrUud+dyyqfMo7B3yBMjwMFlxqGcZaR+Z6nBBXycfarV5huB22huWQc1ioVJdh/jW2R/lqHCIxpqgLPFCP8gPiJffrdWkRlXejqfOKCl5BvFQ7UCABZv8GjLyZXrcD22EGTA1p4b7GFcD0jB5PR1EhP3xERPp6T8dl5o3feqPaha4QIINsd9F3JYsOOaLNcE4JMqIzytwSuJaaH1Jn0PHPTq8VOCKmjvXSTCC1PBAZs43dmllZ/LiLqhTsnrRZzaw== X-YMail-OSG: ihLj15kVM1n3boWyihDeBuo_akpUcG5vNOGSq5dzyU8UoJf3UNZtN4Z3TFbEcOi nfUmfoBHGQbWGWYhM4f4Dz42iiSKDlDpwFnwRr4LYjB_fsmURxP6H7aJw_Pfgd1sC.zjeNm.v03Z dnRvwWjFRVoSW9ANHQc_xY7Hg7py.cjv1wxuwOe322j.w7oXHEpRKEfBeMB16NS5ATIEhNBeg3QH FffJlSBWJzbVj.tXkaU5wOMzwAeB6rU8bJErwQ5n6V.db7k8edDalDyWJ_LPHSFhHe_gszND3BMa VaeklkWVi7r4Fo.MjuhggavmDdu8fFF3Ern1lys_h3excNiqqw.ro1K2Cb9q5Pdd4scvDR7oj9nH t4ZldY48r0fM6N5_lqZ_2XAEQbkkXISLZVVGbCF0S62vu0RQA8S0pHW_fW0tC1MRw5o4hX6aA1Du SUGzCAI9GTnsBJnH5hlPqaYVjA0OZhF55tVqOluOlEdcCGxtQNMvZJoHj28O4MC_jksVb02uVzLy AYVeQncDUxpYBmm7iN9_rAqQZGL.7CqQg_X.G4lagBtcNBud86blANJqRH6Zz.xa5xhKq.gqDNIb WZUhNayzOjhtzF.H.7lauc6P0v3Ox1.ZrKbTXzIJXNCu6br9OtzFUM6LeS2ocha8tes0mx92gOMY cAMF05_kT2X7LWa4tO0KEtisAk4Pm.iidiBSGwhB9GsLj7k6cQQOCSGfVjwpmXE1KfqHmJx5csQK OWrc_O_0Yg7Ie0RMQI3rN82n4tgnL66nLqkCMvxUbx9HoVb4P8f14PTSB8Ghij60rIvWCDYWy5Xf lJJJFwxXBGG9N_p3qliQgb.nAc9qfbQ_pD6odyHkGb Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ir2.yahoo.com with HTTP; Fri, 6 Sep 2019 10:30:35 +0000 Original-Received: by smtp404.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 90b6d2aacf6789c8792ff816954360ad; Fri, 06 Sep 2019 10:30:33 +0000 (UTC) Content-Disposition: inline In-Reply-To: <8336h97qiw.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.178.201 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:239895 Archived-At: On Fri, Sep 06, 2019 at 11:55:19AM +0300, Eli Zaretskii wrote: >> Date: Thu, 5 Sep 2019 19:26:09 +0000 (UTC) >> From: Ergus >> Cc: eliz@gnu.org, emacs-devel@gnu.org >> >> I attach here a new patch with all the changes I have just made. After fixing the latest Martin's issue there was >> exposed a new issue maybe related with the initialization per line. (picture attached) > >Thanks. I admit that I'm confused by your patch: I don't understand >your design of calculating and applying the face used for EOL >extension. E.g., where's the code that merges only the non-extensible >attributes of the face at buffer position and assigns that face ID of >the calculated face to it->extend_face_id? 1) This is something confusing even for me. because I was doing that the other way around as in my initial mental scheme the "extensible" part of the face should be associated (somehow, contained or mapped) with every extensible face || else 0 (DEFAULT_FACE_ID). So it will be easy to check that and go forth and back at EOL. >And why did you copy all >the lines that assign to it->face_id with similar lines that assign >something similar (sometimes identical) to it->extend_face_id? 2) This was a desperate try to check where I was caching something wrong. In some cases it will be needed to do that because there are points were the face_id is set and reset latter and it is faster to cache also the extend_face_id instead of calculating it because there is not conversion method. (explication at the end) >And >why do you have to save and restore extend_face_id during some >operations, like we do with it->face_id? Etc. etc. > 3) Same than above. Hopefully this will be removed. For some reason before Martin faced the issue he reported on yesterday, the code was somehow working for me more or less as expected. So it seems to be that something was not initialized and hiding the bigger issues in my part. >Can you post a description of the design and the implementation, to >help me find the light here? In particular, I don't think I >understand the meaning of "the face should be extended after EOL", if >that face is merged with other faces to realize the face to be >actually used in display. This semantics seems not to be explained >anywhere, so it's hard to judge whether the implementation satisfies >the requirements/expectations. > 4) Sorry for that. the face should be extended after EOL means (somehow) that the attributes specified in the face are merged with the ones in other extensible faces to extend after EOL. The conditional to merge (probably wrong) is in merge_extend_glyph_face in xdisp.c. >> The issue is actually related with the fact that extend_face_id is never restarted to face_id when going back >> from an extend to a non_extend face between lines (for example when mark is active and the iterator crosses >> the pointer to outside the selected region like in the picture). > >I cannot answer this question because my mental model is the opposite: >that the code should temporarily set face_id to be equal to >extend_face_id when producing glyphs beyond EOL, then reset face_id >back to its previous value. But your code doesn't fit this mental >model of mine, so I'm probably missing something. > 5) This is actually what happens more or less. in exted_face_to_end... I set the face_id = extend_face_id and then I reset it back at the end (as usual). The issue in my code is probably that I am not calculating the extend_face_id at EOL correctly. (Mainly because I know I am missing something crucial about where and how to do that.) Actually extend_face_id; once it is set to an extensible face it only merges forth and forth... so even after the region finishes it never resets.... which is actually wrong (my bad)... but I don't know where this happen for the face_id; that's why I was reassigning everywhere to see if I could find it. >> I made all the updates of the extend_face_id in the same places where face_id was updated (even when >> uneeded for now.) > >This is another place for confusion: I don't understand why >extend_face_id should be updated in all those places. In my metal >model, extend_face_id is independent of many/most of the factors that >cause us update face_id. > I know. I just couldn't find a condition... sorry for that. >> But I don't see any special function that is called before >> display_line. > >face_id is initialized in init_iterator, which is always called once >before the first call to display_line. Thereafter, any subsequent >call to display_line "inherits" the value of face_id left in the >iterator object at the end of the previous call to display_line. > I understood this later actually. > > >Whether this fits the logic of using extend_face_id, I cannot say yet; >see the above questions that describe my confusion. > It actually does... but when the it->face_id changes (for example the region ends in the middle of a line) the extend_face_id should know. >Thanks for working on this. I am actually rethinking the whole code... but I need to understand better some details that are unclear for me. Like how to get the "extensible" face_id from a non extensible mixed merged face. Lets say e = (a + b + c + d) where only a and c were extensible. Because if I don't have a cache/face I will need to recalculate that every time and find a way to remember how a face was composed... (remember that e was composed by a; b; c; d and then iterate over those ids, get_face_from_id and do a loop that if EXTENSIBLE-P will merges in extend_face_id. This will be sub efficient. The other problems I see with this is that in general after several merges the resulting face_id could be the same for different sequences of a, b, c, d, f, g, r. So the relation face_id -> extend_face_id is not even injective; as we lost information in the middle. The simplest case: suppose that we have (h == b) but h is extensible and b is not. they both will have different face_id because the vectors are different. Merging (a + b + c + d) == (a + h + c + d) -> same face id but the extensible faces (a + c) != (a + h + c) -> different face_id So I don't know how to face this if I want to do it at the EOL only. Because of that I was somehow searching for a method that could give me (a + h + c) or (a + c) on the fly every time... but this seems to be wrong implemented; so I need MORE help here.