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: Thu, 25 Nov 2021 15:28:43 +0200 Message-ID: <83ee745ppw.fsf@gnu.org> References: <87bl2hyzca.fsf@gnus.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> <837dcx8kkn.fsf@gnu.org> <87czmofl3z.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2657"; 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 Thu Nov 25 14:33:12 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 1mqEsC-0000VT-0G for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Nov 2021 14:33:12 +0100 Original-Received: from localhost ([::1]:59460 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mqEsA-0008Eq-Vb for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Nov 2021 08:33:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39384) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mqEnt-00030L-Bg for emacs-devel@gnu.org; Thu, 25 Nov 2021 08:28:45 -0500 Original-Received: from [2001:470:142:3::e] (port=41344 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 1mqEnr-0000Xn-89; Thu, 25 Nov 2021 08:28:43 -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=vsRtjrHrSiX0z1q/PRFYhyhsMhCKnfwYU3muexRd8ZE=; b=oMo2JxM5ViJw zwqxh3wX0/OzpcLe2qLdDPcGM8+mJA+6mk7lpIOo2D+AQ+HOLzTqaANLZyD0dQM6eG4Ur4iCaUpz/ wzVsM3RlN66hFJ7JDPx4Td4/otO2QjaG4Ydmd4jtYyx1xeF4y/jINGdw5FzIzGPfcQ1QD3Snk2QLZ YzcEk/kEXGep4qDoLGAZDhUHJUsApanJbOzgum44OIKhF2BsgpfsmKFHjWTd5XbKcmEwEq76XubpH Ylz1h9GHcNw/qMjtWLGuR7GLgMjCi7JcIUxITZ0QKfD1e3fMGQIt1o6EiiK7U2xt83gFp6YdtrQcq IA87PwHLfgxP+O2hyB70UA==; Original-Received: from [87.69.77.57] (port=3075 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 1mqEnq-0007nh-Tz; Thu, 25 Nov 2021 08:28:43 -0500 In-Reply-To: <87czmofl3z.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 25 Nov 2021 13:58:08 +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:280117 Archived-At: > From: Lars Ingebrigtsen > Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org > Date: Thu, 25 Nov 2021 13:58:08 +0100 > > Eli Zaretskii writes: > > > 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. > > Oh, you mean keep adding when the min_width eq-ness doesn't change? I > guess that could work, but I don't see how that'd simplify anything. It might simplify things because you won't need display_min_width to be called the second time by property (in)equality, but just based on position. Also, you don't need to keep the form in the iterator, which could help GC. > >> 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. > > I've tested, and it does. It's only apparently in specs like > " (%l,%c)", though. Well, that's expected: you are formatting two strings. > > I'm afraid that I'm missing something important here. > > Yes, when called from the mode line we're postponing the stretch > computation until the :propertize run is actually over (in the > multiple-% case). But "is over" seems to mean "we are in the next string", not "we are at the end of the string that needs to be stretched". that's what the bufpos == 0 test does. Right? If so, this is too late: what if there's no "next string"? > > (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.) > > Well, the stretch isn't realised until there's something to stretch too. ??? The "foo" part has the display property, so it is that something which needs to be stretched. That there's some more text after it shouldn't affect how "foo" is displayed, right? Or what am I missing?