From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Fri, 06 Sep 2019 11:55:19 +0300 Message-ID: <8336h97qiw.fsf@gnu.org> References: <318675867.1913640.1567711569517.ref@mail.yahoo.com> <318675867.1913640.1567711569517@mail.yahoo.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="204806"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 06 10:55:53 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 1i6A24-000r52-2K for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 10:55:52 +0200 Original-Received: from localhost ([::1]:53652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6A22-0004Vd-IM for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 04:55:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54609) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6A1a-0004VX-Fe for emacs-devel@gnu.org; Fri, 06 Sep 2019 04:55:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i6A1Z-0007Y8-Um; Fri, 06 Sep 2019 04:55:21 -0400 Original-Received: from [176.228.60.248] (port=1536 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i6A1Z-0008JU-2R; Fri, 06 Sep 2019 04:55:21 -0400 In-reply-to: <318675867.1913640.1567711569517@mail.yahoo.com> (message from Ergus on Thu, 5 Sep 2019 19:26:09 +0000 (UTC)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:239892 Archived-At: > 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? 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? And why do you have to save and restore extend_face_id during some operations, like we do with it->face_id? Etc. etc. 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. > 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. > 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. > 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. Whether this fits the logic of using extend_face_id, I cannot say yet; see the above questions that describe my confusion. Thanks for working on this.