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 21:12:06 +0300 Message-ID: <83y2z15m6h.fsf@gnu.org> 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> <20190906163456.7kfylavswxvgrfhv@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="191557"; 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 20:12:17 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 1i6IiW-000nhM-NU for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 20:12:16 +0200 Original-Received: from localhost ([::1]:59134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6IiU-0000CO-Vx for ged-emacs-devel@m.gmane.org; Fri, 06 Sep 2019 14:12:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55213) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6IiO-0000C6-OH for emacs-devel@gnu.org; Fri, 06 Sep 2019 14:12:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i6IiO-0005A1-8D; Fri, 06 Sep 2019 14:12:08 -0400 Original-Received: from [176.228.60.248] (port=3742 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i6IiN-0003Z8-Kk; Fri, 06 Sep 2019 14:12:08 -0400 In-reply-to: <20190906163456.7kfylavswxvgrfhv@Ergus> (message from Ergus on Fri, 6 Sep 2019 18:34:56 +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:239904 Archived-At: > Date: Fri, 6 Sep 2019 18:34:56 +0200 > From: Ergus > Cc: rudalics@gmx.at, emacs-devel@gnu.org > > When you say a variant you mean another function to call directly from > extend_face_to_end_of_line? Yes. > 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? face_at_buffer_position and face_at_string_position collect all the faces that affect a given buffer/string position, and then they merge these faces to produce the face ID to be used by the iterator. By "remember" I meant that if you call face_at_buffer_position for any position between stop positions A and A+1, it will produce the same face ID, because the face properties don't change between stop positions. The data structures maintained by Emacs that determine the faces in effect for a particular position is what "remembers" these faces for you. > 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? What I meant is to write a function like handle_face_prop, but one that instructs face_at_buffer/string_position to merge the relevant faces in a special way, one that takes the :extend attribute into account. Whether the code will be similar enough to what handle_face_prop does now to make them use the same code, is a separate question; I wouldn't be bothered by that at this time. First let's have code that we understand and that works; we can bother about cleaning up and optimizing later.