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: Sat, 21 Sep 2019 11:20:44 +0300 Message-ID: <83v9tmqcv7.fsf@gnu.org> References: <20190906093117.25qfim4kcrmiqunk@Ergus> <83o8zw5zh8.fsf@gnu.org> <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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="184362"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rudalics@gmx.at, emacs-devel@gnu.org To: spacibba@aol.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 21 10:20:48 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 1iBadL-000lna-GP for ged-emacs-devel@m.gmane.org; Sat, 21 Sep 2019 10:20:47 +0200 Original-Received: from localhost ([::1]:40116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBadK-0002Li-7x for ged-emacs-devel@m.gmane.org; Sat, 21 Sep 2019 04:20:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35522) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBadD-0002LM-T3 for emacs-devel@gnu.org; Sat, 21 Sep 2019 04:20:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41140) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iBadD-000769-Jd; Sat, 21 Sep 2019 04:20:39 -0400 Original-Received: from [176.228.60.248] (port=4362 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iBadC-0004VD-N1; Sat, 21 Sep 2019 04:20:39 -0400 In-reply-to: <83blvjw8x9.fsf@gnu.org> (message from Eli Zaretskii on Tue, 17 Sep 2019 12:48:02 +0300) 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:240213 Archived-At: > 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. 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? 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. . 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. . 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. 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.