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: Sat, 21 Sep 2019 15:57:01 +0200 Message-ID: <20190921135701.fbiijvdhe7o6uomb@Ergus> References: <83mufg5yn1.fsf@gnu.org> <20190908005109.s7hhcczkrcbzewdc@Ergus> <83imq24qx3.fsf@gnu.org> <20190908182346.hheaveun2pw5usb6@Ergus> <20190914204207.gfyvgbb7t4ztya7a@Ergus> <83ftkxy3r7.fsf@gnu.org> <20190915214233.xkjtoxyfxkyrd2id@Ergus> <20190917021725.xxhhhxcz3nr6sb7z@Ergus> <83blvjw8x9.fsf@gnu.org> <83v9tmqcv7.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="179556"; 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 Sat Sep 21 15:58:36 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 1iBfuF-000kbE-Dc for ged-emacs-devel@m.gmane.org; Sat, 21 Sep 2019 15:58:35 +0200 Original-Received: from localhost ([::1]:42016 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBfuE-0003rS-4t for ged-emacs-devel@m.gmane.org; Sat, 21 Sep 2019 09:58:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33955) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBft1-0003rB-HG for emacs-devel@gnu.org; Sat, 21 Sep 2019 09:57:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iBfsz-000762-Pn for emacs-devel@gnu.org; Sat, 21 Sep 2019 09:57:18 -0400 Original-Received: from sonic317-26.consmr.mail.bf2.yahoo.com ([74.6.129.81]:38261) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iBfsz-00075f-JI for emacs-devel@gnu.org; Sat, 21 Sep 2019 09:57:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1569074236; bh=NcT3d3i3WnA3prdwXLkM7WF+xmdoeX2a02XzNXZxk8Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=sI0gTn4wfD53oX+JhrmU5fmtdbBKpRhxEbr2fVfLSGvMSkKi+wZRlAAi2NphOEBupTFkR26Yz8bkhMzULng8apNzvGIZGWMSaEzjor6DdPuqn5HqJs8i4qKipbgsuMZBcMJ5id1xDDn7Iuy9bcH0/1ZPcOfK1HLao1VkkCRj8Zkprq1x97fZVMV2WfQdF7xHzEcdNzbl/57lcZGWreKSt9u6J7fq8eaaqTg/pZy+QOzHqjPL8wQxjYjVJesnshPK5fTL0ukOs1dwueOFTT9eKqPSC7ldgkTNsQUxNq7ShAgTk9hfUUlcD+0ZD3J2rWfogwxhiV5SgdjI4RAWeFpMqg== X-YMail-OSG: uRxKvx0VM1lFpESDXazB4lDPoPXcI7HOUAxelt4g2xHIGTIRbRy_SIm.PqLnyS0 Iy1XbbRInC8zdEJQ3bjk0BzZd79CnNwlvx2ZOuW22_clvMY4BnEM.mvoIavUVJwWHDgiVRbukoyw zcc_fImZvlid4TdpasS4rgi9W19xKocg9R7b2qpbv7R8KaxNyKOs8v9ug24WuhcBPXK9pWmh9n.r 7F_CMlB9zVoFkyW4yYaAz62GrWsuUL0cPlCMTeUapStswxbEAs698b55XvfdvZpSFpl8Z5fKtO2c UXT0aZnD168AaOCGyi7b.GvsELlLnntVojoiiEm1cmM4l01jfKZFHyuqUC7mPC8YJBSJUTbbVk26 73SKdFeH45wRMr1YnqAXH3gABttu7O_EDzIZ0iwN7FGXai5vkegaMRj7Le.tzwN0kHZ7Zw0SVr8T owplNasDLD1mM7A927MISNEtjmhQl_rbnr0h.5sx_0jQjdagnS2f4.Pe1ZBxKBmSJtSE2fdFOF_b y5W6p5mM0DU3XgqjPYa7eGa0x3lD.5C_1b_7KAYwJuazdiwvP7Vk8z8C3hvRrq.B6niFcXNFcQGX STE4Tr384tr_CdkhSQFEt5mq8r665u7iUfaHSInZefAVRQbJeVBVg_FYg59YlSSYYYoplnUNN9SY TAZCQB.vLIatapG_gvqALm1PQ3sXY3hkX_0zUPLViz70TnOEyUXaO8nS5rSAMzQaY5XOq3mCJ3yA IdlkarrvvZbxrNjoEWcRWYLlIK9f9WrJRB8WZF.v_YLhYsrCZLO4_Jj.d2Olcddo2MLt0JGQrXs5 3TlQW7x39F6sGlrvJQdW3DPX4wEJtJm60zo2zbCopg Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Sat, 21 Sep 2019 13:57:16 +0000 Original-Received: by smtp422.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7798a05955573c9648a764fa7af51126; Sat, 21 Sep 2019 13:57:11 +0000 (UTC) Content-Disposition: inline In-Reply-To: <83v9tmqcv7.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.129.81 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:240217 Archived-At: On Sat, Sep 21, 2019 at 11:20:44AM +0300, Eli Zaretskii wrote: >> Date: Tue, 17 Sep 2019 12:48:02 +0300 >> From: Eli Zaretskii >> Cc: rudalics@gmx.at, emacs-devel@gnu.org >> >> > Date: Tue, 17 Sep 2019 04:17:26 +0200 >> > From: Ergus >> > Cc: rudalics@gmx.at, emacs-devel@gnu.org >> > >> > >>>>The filter now in merge_ref only works when !CONSP(ref_name). As it only >> > >>>>bypass the extra parameter to merge_named... it this right in the >> > >>>>general case? >> > >> >> > >>I think we should support all the cases, otherwise the feature will >> > >>behave inconsistently, and we will get bug reports. >> > >> >> > >About this; the problem is that in the general case I'm not sure what's >> > >the "right" behavior for the other cases. When !CONSP(ref_name) it means >> > >that the parameter is a face_name; but in the other cases it means that >> > >we are explicitly specifying the attributes as a cons list or as >> > >:atribute value pairs... What's expected to happen in those cases?? >> > > >> > Hi: >> > Any Idea about this? Could you suggest what to do when CONSP(ref_name) >> > is true? >> >> I will reply to this soon, too swamped now. > Hi: Thanks for the reply. >Sorry for the delay. > >Having looked at the code, I'm not sure I understand the problem. Why >not simply pass the attr_filter down to the respective merge_face_ref >calls, where you currently force zero instead? Am I missing >something? > That's what I do actually are you in the last changes? Probably I am the one who is missing something otherwise. >Some other comments about your code: > > . Please rename handle_face_prop_general into something like > face_at_pos, and make it just return the face ID, without assigning > any field in 'struct it'. handle_face_prop will then call > face_at_pos and assign the face ID as needed. Yes, I change that already to return the id without assigning anything. > . handle_face_prop_general is supposed to be called just once with > the last argument non-zero, so I see no reason why it should be > also passed the initial_face_id argument. It looks wrong to call > that function with it->extend_face_id as the 2nd argument, and have > it compute it->extend_face_id, because the value you pass as an > argument is undefined: it hasn't been computed yet. I think the > function should use it->face_id internally instead of that > argument. The initial face if has nothing to do with the last argument. It is needed for an optimization at the end of the function. But yes, using it internally is better. > . I don't understand why you need new members of 'struct it', like > extend_face_id, saved_extend_face_id, etc. > extend_face_to_end_of_line correctly assigns the value of extend > face ID to it->face_id, after saving it->face_id in a local > variable, so I see no need for it->extend_face_id, certainly not > for it->saved_extend_face_id. You also have extend_face_id in > other related structures, where it is never used. > This was for the idea to avoid recomputing it->extend_face_id in some cases, and reuse the previous value when possible too. (that's why I pass it as a parameter face_id actually.) But I can change that if you think it is not needed. >Regarding documentation: if you have difficulties with the Texinfo >markup, you could write plain text, and someone else could then add >markup. Adding markup is a mostly mechanical procedure, unlike coming >up with a useful text. > >Thanks. Thanks to you