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: Sun, 15 Sep 2019 18:32:12 +0300 Message-ID: <83ftkxy3r7.fsf@gnu.org> References: <318675867.1913640.1567711569517.ref@mail.yahoo.com> <318675867.1913640.1567711569517@mail.yahoo.com> <97f66744-8481-084a-ef23-2c50444e1f05@gmx.at> <20190906093117.25qfim4kcrmiqunk@Ergus> <83o8zw5zh8.fsf@gnu.org> <83mufg5yn1.fsf@gnu.org> <20190908005109.s7hhcczkrcbzewdc@Ergus> <83imq24qx3.fsf@gnu.org> <20190908182346.hheaveun2pw5usb6@Ergus> <20190914204207.gfyvgbb7t4ztya7a@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="65281"; 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 Sun Sep 15 17:32:01 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 1i9WVN-000Gsu-Mi for ged-emacs-devel@m.gmane.org; Sun, 15 Sep 2019 17:32:01 +0200 Original-Received: from localhost ([::1]:55590 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9WVM-0001BW-Iv for ged-emacs-devel@m.gmane.org; Sun, 15 Sep 2019 11:32:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47065) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9WVG-0001BK-Io for emacs-devel@gnu.org; Sun, 15 Sep 2019 11:31:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i9WVF-0006sW-Vl; Sun, 15 Sep 2019 11:31:54 -0400 Original-Received: from [176.228.60.248] (port=2323 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i9WVF-0005x2-39; Sun, 15 Sep 2019 11:31:53 -0400 In-reply-to: <20190914204207.gfyvgbb7t4ztya7a@Ergus> (message from Ergus on Sat, 14 Sep 2019 22:42:07 +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:240048 Archived-At: > Date: Sat, 14 Sep 2019 22:42:07 +0200 > From: Ergus > Cc: rudalics@gmx.at, emacs-devel@gnu.org > > >I implemented this in the face_at_buffer_position but in the same > >function (handle_face_prop_general) there is a function called > >face_at_string_position equivalent to face_at_buffer_position... is it > >possible in some conditions to reach that part of the code at eol? if > >so I will need to modify that one too maybe right? Yes, it's possible. You need to arrange for a display string or an overlay string with en embedded newline. > >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. > Could you suggest (if any) if there are some conditions we can use to > avoid the call to handle_face_prop_general in some cases? Why, did you see any tangible slow-down of redisplay due to these changes?