Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 18:50:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> 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 ;-)