bug#52676: 28.0.50; [PATCH] Rationalize window-text-pixel-size

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Date: Sun, 19 Dec 2021 21:32:15 -0500
> 
> Even if 43c4cc2 did anything (it doesn't), it was obviously
> the wrong way to go about it.

It's WIP.  It's too early IMNSHO to judge it, because alone it does
very little.

>    start_display (&it, w, startp);
> -  int start_y = it.current_y;
> -  /* It makes no sense to measure dimensions of region of text that
> -     crosses the point where bidi reordering changes scan direction.
> -     By using unidirectional movement here we at least support the use
> -     case of measuring regions of text that have a uniformly R2L
> -     directionality, and regions that begin and end in text of the
> -     same directionality.  */
> -  it.bidi_p = false;

Why was this removed? what's the rationale?  Did you understand the
underlying problem about which the comment hints?

> -  /* If FROM is on a newline, pretend that we start at the beginning
> -     of the next line, because the newline takes no place on display.  */
> -  if (FETCH_BYTE (start) == '\n')
> -    it.current_x = 0;

And why was this removed?

> -  if (!NILP (x_limit))
> -    {
> -      it.last_visible_x = max_x;
> -      /* Actually, we never want move_it_to stop at to_x.  But to make
> -      sure that move_it_in_display_line_to always moves far enough,
> -      we set to_x to INT_MAX and specify MOVE_TO_X.  */
> -      move_op |= MOVE_TO_X;
> -      to_x = INT_MAX;
> -    }

And this?

> -  /* We could have a display property at END, in which case asking
> -     move_it_to to stop at END will overshoot and stop at position
> -     after END.  So we try again, stopping before END, and account for
> -     the width of the last buffer position manually.  */
> -  if (IT_CHARPOS (it) > end)
> -    {
> -      end--;
> -      RESTORE_IT (&it, &it2, it2data);
> -      x = move_it_to (&it, end, to_x, max_y, -1, move_op);
> -      /* Add the width of the thing at TO, but only if we didn't
> -      overshoot it; if we did, it is already accounted for.  Also,
> -      account for the height of the thing at TO.  */

And this?

So basically, you removed code which was there to handle real
problems, with no explanations and with log messages whose content
includes no useful information.  The Git history should have pointed
you to the bug reports and discussions which caused us to add those
code fragments you removed, with recipes to create those problematic
situation; did you try those recipes? did you find them not
reproducible, or thought that the fixes are no longer needed, or have
better ideas for how to fix them?  If so, how about including all that
information in your patch submissions?

Without all this information, how can you expect us to use your
patches?  All I see is that you delete code that is there for a
reason.