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 16:28:20 +0300 Message-ID: <831rwt7dvv.fsf@gnu.org> References: <318675867.1913640.1567711569517.ref@mail.yahoo.com> <318675867.1913640.1567711569517@mail.yahoo.com> <8336h97qiw.fsf@gnu.org> <20190906103023.3r7aa5spkie3cca6@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="29957"; 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 15:29:09 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 1i6EIX-0007XB-5Z for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 15:29:09 +0200 Original-Received: from localhost ([::1]:56308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6EIQ-0004mv-Hs for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 09:29:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37462) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6EHq-0004mm-RG for emacs-devel@gnu.org; Fri, 06 Sep 2019 09:28:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i6EHq-00052M-BS; Fri, 06 Sep 2019 09:28:26 -0400 Original-Received: from [176.228.60.248] (port=2211 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i6EHn-0005cm-Df; Fri, 06 Sep 2019 09:28:25 -0400 In-reply-to: <20190906103023.3r7aa5spkie3cca6@Ergus> (message from Ergus on Fri, 6 Sep 2019 12:30:23 +0200) 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:239900 Archived-At: > Date: Fri, 6 Sep 2019 12:30:23 +0200 > From: Ergus > Cc: rudalics@gmx.at, emacs-devel@gnu.org > > 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. So the face we use after EOL should be the result of merging only those faces which have their :extend attribute set to non-nil, is that right? > >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. Should it? The way I see it, we don't need to care about extend_face_id until we actually come to EOL. > 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. I don't think you need to remember anything, because Emacs "remembers" for you. All of those faces (a, b, c, d) will still be in effect at EOL (i.e. at the position of the newline character); all you need is to merge them there while ignoring those of them whose :extend attribute is not set. IOW, I thing extend_face_id should only be computed at EOL, either in extend_face_to_end_of_line or in append_space_for_newline. Because you don't need that face ID before you come to EOL. > 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. I think the solution should be to have a variant of the code in handle_face_prop such that it computes the face at EOL. It would do that by modifying face_at_buffer_position and face_at_string_position to accept an additional argument EOL_P, which means merge only faces which have their :extend attribute set. Then the face ID computed for this specially merged face should be used as extend_face_id. Does this make sense?