From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Tick Reduction Date: Wed, 24 Nov 2021 20:39:20 +0200 Message-ID: <837dcx8kkn.fsf@gnu.org> References: <87bl2hyzca.fsf@gnus.org> <87h7c5jmbg.fsf@gnus.org> <838rxhqmqv.fsf@gnu.org> <878rxhjlot.fsf@gnus.org> <874k85jlmq.fsf@gnus.org> <87v90khaa8.fsf@gnus.org> <83zgpwp7v2.fsf@gnu.org> <87tug4fdn7.fsf@gnus.org> <83pmqsp0m7.fsf@gnu.org> <87k0gzyy8k.fsf@gnus.org> <835ysjoupv.fsf@gnu.org> <8735nnyob1.fsf@gnus.org> <83y25fneeh.fsf@gnu.org> <87pmqrx7rh.fsf@gnus.org> <83tug3ndaj.fsf@gnu.org> <874k81vmlf.fsf@gnus.org> <83sfvl8wjw.fsf@gnu.org> <87o869y0v2.fsf@gnus.org> <83fsrl8owz.fsf@gnu.org> <87o869wkcx.fsf@gnus.org> <83bl298n9b.fsf@gnu.org> <8735nlwih6.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31672"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 24 20:03:09 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mpxXw-00080i-1S for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Nov 2021 20:03:08 +0100 Original-Received: from localhost ([::1]:59744 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpxXu-0004VX-Gy for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Nov 2021 14:03:06 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50158) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpxAv-00064s-MU for emacs-devel@gnu.org; Wed, 24 Nov 2021 13:39:22 -0500 Original-Received: from [2001:470:142:3::e] (port=42668 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpxAv-0005Yd-8u; Wed, 24 Nov 2021 13:39:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1nxqaQpglj7bOaZ/UV/Z97sNr679jXxu+vupiLDTr1Q=; b=ZYttKnpUdOWa bWIa53EB6e1FRAwj4OHtvVvKeQkso5URrrgsCQv8XiuG2KsvrBX80FB//y5qS6HuSTNtVzzRp+E9P 7bitZM5W4diBDkP1i/rIbUJNXcqtWTdr9FFICvSou7S2YnG45bSJLPlPZun8PdP5tkoU8cFcciZOs rD3kFsM0HOoz8D8sgzHtzj/H9b2++EnT7fLorFJJtObN+0ggnqEe3SGIn/KKH9I4NE1DjgPNHVh0b yRVVwqa6t+U3BzXL7VMD57AcoTxr/gu8ZjX6bcFY3dD9Dyq8H4DnjkoyP821os93fK/oVTGTjvDKH dtgEq5zRWVeohIb8jfEV+w==; Original-Received: from [87.69.77.57] (port=3990 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpxAu-0005Uf-Ui; Wed, 24 Nov 2021 13:39:21 -0500 In-Reply-To: <8735nlwih6.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 24 Nov 2021 18:50:45 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:280041 Archived-At: > From: Lars Ingebrigtsen > Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org > Date: Wed, 24 Nov 2021 18:50:45 +0100 > > Eli Zaretskii writes: > > > There's the display_prop_end function we normally use for that. > > I don't quite understand. If I have a max-width going from 5 to 15, > and a height going from 10 to 12, I think this function is going to be > called at 5, 10, 12 and 15? I need to know that this consecutive series > of characters ends at 15. You cannot usefully have two display properties with different values (one min-width, the other height) which overlap. But yes, display_prop_end will fund the next position where the display property changes its value. Why is that a problem? The idea is that whatever tests you need to do to with the position it finds, you do them at the beginning of the property, then you record the result in it->position, and use that to know when you are at the end of the property. > It's the same issue when called from display_string -- the mode line > machinery will call the function several times, even if the :propertize > is around all the specs. I don't think so, but maybe I misunderstand something. > > And I'm confused by the fact that for buffers you test > > > > if (bufpos > BEGV && EQ (FOO, BAR)) > > > > whereas for a string you test > > > > if (bufpos == 0 && !EQ (FOO, BAR)) > > The bufpos == 0 is just testing that we're being called from the mode > line (where it's always 0). But that isn't guaranteed. This display property can be on some part of the string, and doesn't have to start at position zero. > > and also why is the first case tests equality, whereas the second one > > tests INequality? > > Looks correct to me -- one is testing the start of the range and one is > testing whether we're at the end. ??? But the code under the test does the processing that's appropriate for the end of the property, doesn't it? Namely, it computes the width of the stretch that needs to be appended for padding. And both conditions, when fulfilled, trigger the same code: if ((bufpos == 0 && !EQ (it->min_width_property, get_display_property (0, Qmin_width, object))) /* In a buffer -- check that we're really right after the sequence of characters covered by this `min-width'. */ || (bufpos > BEGV && EQ (it->min_width_property, get_display_property (bufpos - 1, Qmin_width, object)))) { Lisp_Object w = Qnil; double width; #ifdef HAVE_WINDOW_SYSTEM if (FRAME_WINDOW_P (it->f)) { struct font *font = NULL; struct face *face = FACE_FROM_ID (it->f, it->face_id); font = face->font ? face->font : FRAME_FONT (it->f); calc_pixel_width_or_height (&width, it, XCAR (it->min_width_property), font, true, NULL); width -= it->current_x - it->min_width_start; w = list1 (make_int (width)); } I'm afraid that I'm missing something important here. > > IOW, the issue here AFAIU is that you might be called to display > > buffer text with this property or to display a Lisp string with this > > property, so the tests should be equivalent, and the only difference > > between strings and buffers is that text starts at BEGV in buffers but > > at zero in strings. So why there are more differences that that? > > What am I missing? > > Like I said, there's no strings -- only buffers and mode lines. Once again: displaying the mode line _is_ displaying a string. The mode line is constructed from Lisp strings. > I.e., this doesn't work: > > (string-pixel-width (propertize "foo" 'display '(min-width (1000)))) I don't think this is related. First, as you well know, string-pixel-width inserts the string into a temporary buffer, and then measures the dimensions there, so this has nothing to do with display properties on strings, as the implementation eventually walks text of some buffer. And second, the current implementation seems to have bugs, because this trivial variation of your original test case: (insert "|" (propertize "foo" 'display '(min-width (8.0)) 'face 'match)) doesn't work, either. (All I did was remove the final "|" from the inserted string.) So I think it's too early to use the code behavior as the evidence of anything ;-)