emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tick Reduction


From: Eli Zaretskii
Subject: Re: Tick Reduction
Date: Thu, 25 Nov 2021 15:28:43 +0200

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 13:58:08 +0100
> 
> Eli Zaretskii <eliz@gnu.org> 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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]