From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Tue, 13 Aug 2019 10:17:32 +0200 Message-ID: <7ba80ec4-d7e2-1f69-5b55-00a8c1851cb4@gmx.at> References: <83k1bpasic.fsf@gnu.org> <20190807155738.yviofsumjjhqueci@Ergus> <83imr9ar9f.fsf@gnu.org> <0975890b-37b4-428d-f6e5-5dcf894fb6be@gmx.at> <83ftmdapxm.fsf@gnu.org> <20190808083804.ta3evocyb4hirywj@Ergus> <20190808145015.2qaxwzwf4ws2i3er@Ergus> <83ftm98dgu.fsf@gnu.org> <5361a037-d204-b746-790f-ee2ea09459e6@gmx.at> <83o90vu6ws.fsf@gnu.org> <831rxqtnaf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="104313"; mail-complaints-to="usenet@blaine.gmane.org" Cc: spacibba@aol.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 13 10:17:59 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 1hxS0E-000Qzv-HG for ged-emacs-devel@m.gmane.org; Tue, 13 Aug 2019 10:17:58 +0200 Original-Received: from localhost ([::1]:50102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxS0D-0007qu-5a for ged-emacs-devel@m.gmane.org; Tue, 13 Aug 2019 04:17:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41404) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxRzt-0007qm-NU for emacs-devel@gnu.org; Tue, 13 Aug 2019 04:17:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hxRzs-0003tr-EG for emacs-devel@gnu.org; Tue, 13 Aug 2019 04:17:37 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:52491) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hxRzs-0003t6-1F; Tue, 13 Aug 2019 04:17:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1565684251; bh=uIUnVQ+DkKJ+W2nCp+IA6XkiZsW17OCpDuyPjIpD7gA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=PVVmP9IrmNEyzR8nNep9j//lDaj6LOFFI7o5SdlBmlfGNOH0CoEGKH5bq/UcNd7Zo ysCIRA9v6abrpGBYVqxa2XF7ri0AKaAwNDS32gkMeq5NSCVu6D/Ur32a+3OKJYozYf tOWHekABze28CSbSAGF/0LXtO3DQFI3fcTMjDF2A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([213.162.80.252]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M5csW-1iCuVX2RZ2-00xZig; Tue, 13 Aug 2019 10:17:31 +0200 In-Reply-To: <831rxqtnaf.fsf@gnu.org> Content-Language: de-DE X-Provags-ID: V03:K1:lNoYW+k6LfkhvgCD2Tm2U7RcgdF7sJ9fSoOLyNRqgyHtpPtvEYy wumd9t960PrjDBSUaKIB9yEy/zARyisprpQ1WJO2Y9Dkaaz8+W61Zlis9kl5vm8HE0TrUbM vOfeXibGPgpsNhHXLGMgf0diG38pPF2jSxaAVCZ50MbQK5vM0gAU3s6mGE7BpHrWRzkAVsp +qpJb2ymxG7a0CvZh0a5A== X-UI-Out-Filterresults: notjunk:1;V03:K0:wK80llSuRkg=:gXAdw9kIZcjLeJ2EeWYSJ8 59/HeFhh2KMXuHZTyY2KFSYP/BZQ5kn+KyLsQcByF8UUneXQJHDXFTBg7ZwuIr5UE0xpdimW3 Ug4Y3XLn6Pox5evk8qFOfNh8jxZbnmElpWG11OlPxIvgpSno7/NxbCIiUZTBI7FrDqAwNLeDm PuTnLMQvm1veqd9bDQVYHz7V+RIL9a5m/c43svJSfh59zUSFPp2p5uu08PxPWZVl+DqDWhI0o +0PifuJApnmz+sLlDe2Ol08uoW0bYuFutZfCB6AyVy+tQvlDEwfz12Stff1Dpv5o6nC25bIe0 zD2L26uBG9Ih8wS9nHECT5fjzAOCz0xzspr3Gw8Bf0lkMfH5PdJfeERltprDGsGV4mm+o8lxU CgXyATXYr3AXu/TmxT3pqK/9j3jCKGBPXTIDSgY37915eeMwn3ADsT62Oa4f/ybFrmlqKtNXv YrPNEJqweEIugD7SqdbfP5kQEiRratadMs1+m0IzHigJFOh5eEvAdl2q+un7CLmf0Ks7ZP2Ee YRfXMo7cbcSAH2ZXtM+zJZ1Q7w89WP8I9Af5V/D9GYvv4u206jR2ILPGNX89BGQovAoH8Lkzi EuXWK3n0rQug2E7WGn27SSICR9Xb0x3iym9R2dEZIIHKgslB1IjBRPwczQ70Ldi6jp/YQdq+m obkyrpv45yTfTWYLJRZP4Fhq78FSbe07+WPtN9Mtm7NdSKwk5FIklqXl10HdtHiPS+NlPenVA y6qKWCGyyUZkRMkgCoijdYXwYQpVxBqs4dB97hxRMMcXToSrrHo1xH6PPDv81o4XCJ9AeGsw X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.22 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:239340 Archived-At: >> IIUC the last one found by face_at_buffer_position that explicitly >> specified a value for the attribute in question. That is, the face >> whose attribute is actually used by the display engine. > > Nitpicking: the display engine has no idea whose attributes it is > using, see below. In an earlier mail I labelled the display engine as "face agnostic" so I am very well aware of that. What I tried to point out (and failed) so far is precisely how to work around that issue. > If two or more faces of those merged specify :underline, and only one > of them has a non-nil :extend, will extending the underline do what > the users expect? It's the last face whose (1) :underline attribute is merged in _and_ whose (2) :extend attribute is set (nil or non-nil) that determines whether the underline extends or not. Whether that is what the users expect is beyond my knowledge. We can only try to provide a fairly consistent way of specifying it. > (And shouldn't we simply disregard entirely a face whose :extend > attribute is nil? What can such a face possibly contribute in this > case?) Consider a user who sets the :extend attribute to non-nil for the 'default' face and wants a 'link' background to not extend to the end of line. Such a user would want to set the :extend attribute of the 'link' face to nil to get the desired effect. > You seem to assume that the iterator examines faces at every buffer > position it passes, and in particular on the newline at EOL. I certainly do not assume such a thing. But when trying to find out how face attributes are merged and realized, face_at_buffer_position was the first point of reference where I found that (and I still don't know a better one). > But > that's not what happens, because examining and merging faces is > expensive, so Emacs avoids doing that unless necessary. We only > examine faces where they change, and use next-single-property-change > to find the next position where we should again examine the faces. That's exactly what I expected but did not find immediately. If you tell me where to look for that (Fnext_single_property_change _is_ called by face_at_buffer_position) "examine faces where they change" and in particular where a :background change is found and applied, I probably could tell you more. > In addition, face_at_buffer_position doesn't look for face attributes > one by one. Instead, it finds all the source of the 'face' property > that are in effect at the given position -- the default face, the face > from text properties, and from all the overlays at that position -- > and merges these attributes into a single attribute vector. Then it > looks up a realized face with identical attributes, or realizes a new > face if no such face exists. Thereafter, the iterator just uses that > face until the next checkpoint. IOW, face_at_buffer_position returns > an ID of a realized (i.e. fully specified) face created by merging > several relevant sources of face information, and that realized face > has no references to the names of the individual faces from which it > was created, nor any memory of which non-unspecified attributes came > from which face source. When face_at_buffer_position puts some 'background' value into that single attribute vector, it can simply set an 'extend_background' bit in that vector which tells the display engine whether the background specified by that vector shall be extended or not. Note that that 'extend_background' bit would be left alone when the face specifying :background does not also specify :extend. In that case the value of :extend of the last face merged in that specified both would persist. > So to implement something like above, we will have to: > > . force face merging when we get to a newline (btw, what about > continuation lines in this context? do we apply the extension logic > to them as well?) I never show continuation lines (with exception of the minibuffer where I have no choice) but I suppose we should apply the extension there as well. Think of the region spanning several continued lines. > . modify face_at_buffer_position and its subroutines to behave > specially when called on a newline, I strongly doubt that this "called on a newline" is needed. Setting the 'extend_background' indicator is strongly tied to the last setting of the 'background' indicator in the attribute vector as done by the face merging algorithm. > and decide whether to merge or > not merge attributes based on whatever data structures describe the > preferences for extending those attributes; this would go at least > two levels below face_at_buffer_position > . do something similar in face_at_string_position, for display and > overlay strings with embedded newlines > > Sounds like fun project. Volunteers are welcome. If all these were really necessary, I'd never vote for such a change. martin