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 18:34:56 +0200 Message-ID: <20190906163456.7kfylavswxvgrfhv@Ergus> References: <318675867.1913640.1567711569517.ref@mail.yahoo.com> <318675867.1913640.1567711569517@mail.yahoo.com> <8336h97qiw.fsf@gnu.org> <20190906103023.3r7aa5spkie3cca6@Ergus> <831rwt7dvv.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="117085"; 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 18:50:38 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 1i6HRV-000UJl-Gu for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 18:50:37 +0200 Original-Received: from localhost ([::1]:58614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6HRU-0003W7-0m for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 12:50:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60109) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6HCX-0004iC-Fr for emacs-devel@gnu.org; Fri, 06 Sep 2019 12:35:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i6HCV-0004hy-1M for emacs-devel@gnu.org; Fri, 06 Sep 2019 12:35:08 -0400 Original-Received: from sonic311-14.consmr.mail.bf2.yahoo.com ([74.6.131.124]:33059) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i6HCU-0004hD-TZ for emacs-devel@gnu.org; Fri, 06 Sep 2019 12:35:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1567787705; bh=5rpAsQK5vRPs4tvIyklfgix6tTIcdA4+fj4/g3ZOAdY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=hCfsuiezA54acBHWyZwo4o6tokLBCloGKot1FRccEit4Q6IzcRiiYR1ZJ59EQP5c7EGSOzh9nfNbFczMafnfhjZWkjaZh0UkrnJh2w4CZ7CazoiCoQeSzhSsIwg6OqfaEoTv3ja1l821bFVbpdPVuo2e+sSnSdOm6ciBa6f6iewKAzt+s7rbXQPRK/g5JkVjPfXHr1p360sHesNgSZZF6oI7hnnB6OMpUpo0XtjzirIeTorAqyC+h9EEKJoaKv/5pGtVD1g0bMNP69wsATtkTkZgJnr4VmiqdCYi3vBJJaZi8fFCs+aEDyNMEmcoLlcClRgY+haV6Gm/paaFqfAFJg== X-YMail-OSG: EnmbXOkVM1nH611j5RACQTxeAuF4Ttmj_q1IduyFuAYO5XQyB3zTfxwJnll2Gc3 BYM.MEF.s6uVFkDHwXacW_9Pjzqjxi6FgqAwnk_b5aGy.WPO1odHDBRF9s49CBRqpZCC5LkC0gH2 XiFOZIvVW5teHnTuNSDITmOw5FcAmN8TvhS5s0mkrdz76Otox4Mr7vjzYYtKakGis.ix.o4MR3i4 .LhS6RVflo4yQza8GW2_JgWQIoCz0om1Ien0ZzGeM7WObAdVhs_I.ogCugnk2IR99IAQcDwYUOes KgowJyLYUDwIiJUigfOhyXmVa7zrcl1nFwk0kGGFBmkPUqTo1Wp.LSMbNxjusZrDK6_9WtRTraHm i7J5Ns3_vdRNkOVCd_vCrtyJ5ug4XnxFhhou8X5SchMDYkTBcgWWuY4mnsNbcJcBf7yo.115MFiK .NGP.2PHgc9m52xKRSRuuNM6rLh673xpLOHsxwRKNPT3kam0HuiBAzBcQVWxwMhfcZURo5QXHpIS D.Koqzw192m86mplxY68ZZRe8IrzC9tF5NUXP4HcxZDCASC3XwhMGez1N62RvFjjHubbiFaBw7bb 7cf.uGbu3RxAbW4jsQs6CwbvkAsKgETug6Tkx7DZd1gMGfKdA_uyE1uk7fbhSe2hmkXQHsXotzVH x9e5m5nX5LoFA._pPk.RJIltKj99eFFeVsdVKixqLFw.d6xUKQ2pO7jg.Mqs8RgWTk1GUHSGfg_H 0SA4s4jYx.CD39NRz37KnORNwYIVcNbmHl4avgakgvAVHi8Sw0K9jh529tuCpvo55v0x.8D0iSVe rh.eWHqLaJcLW9fCaG6TqXDRhWVsTIbLIhJWoZW8yw Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Fri, 6 Sep 2019 16:35:05 +0000 Original-Received: by smtp401.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ef5bff3fbb38084c424edbe3b63ce25d; Fri, 06 Sep 2019 16:35:04 +0000 (UTC) Content-Disposition: inline In-Reply-To: <831rwt7dvv.fsf@gnu.org> X-Mailer: WebService/1.1.14303 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.131.124 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:239903 Archived-At: On Fri, Sep 06, 2019 at 04:28:20PM +0300, Eli Zaretskii wrote: >> 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? > Yes. >> >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. > You are right. >> 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. > append_space_for_newline is not called in all the cases. and this has to do with the yesterdays question about what face should have the extra space (before extending). >> 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? > Probably yes but more questions :) Lets say that I actually don't understand very well what handle_face_prop does (when it is called and when not). When you say a variant you mean another function to call directly from extend_face_to_end_of_line? Sorry I still don't understand where is (a + b + c + d) computed or where emacs "remembers" that, or if it is computed all the time. But maybe the trick is actually in face_at_buffer_position, face_for_overlay_string or face_at_string_position? If so; then what we really need is a variant of face_at_buffer_position like extend_face_at_buffer_position? (or add to it a parameter to do what we want) does it makes any sense. handle_face_prop can't be modified as it should have a specific prototype. But we can make it a wrapper and create a generalized or use ITERATOR_AT_END_OF_LINE_P internally?