bug#45748: 28.0.50; fit-frame-to-buffer ignores leading spaces

[Eli Zaretskii <eliz@gnu.org>]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 9 Jan 2021 10:27:12 -0600
> 
> On Sat, Jan 9, 2021 at 9:57 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> >
> > I believe the problem is with:
> >
> > (window-text-pixel-size nil t)

You mean with

  (window-text-pixel-size t t)

right?

> > The FROM of t causes window-text-pixel-size to ignore leading spaces.
> > A TO of t, causes it to ignore trailing spaces. fit-frame-to-buffer
> > passes both as t. This is hardcoded unless you use
> > fit-frame-to-buffer-1

??? fit-frame-to-buffer always calls fit-frame-to-buffer-1, sow hat do
you mean by "unless"?

> The problematic code appears to be here in window-text-pixel-size:
> 
> else if (EQ (from, Qt))
>   {
>     start = BEGV;
>     bpos = BEGV_BYTE;
>     while (bpos < ZV_BYTE)
>       {
> c = fetch_char_advance (&start, &bpos);
> if (!(c == ' ' || c == '\t' || c == '\n' || c == '\r'))
>   break;
>       }
>     while (bpos > BEGV_BYTE)
>       {
> dec_both (&start, &bpos);
> c = FETCH_BYTE (bpos);
> if (!(c == ' ' || c == '\t'))
>   break;
>       }
>   }
> 
> The second loop looks like it's attempting to backtrack to the
> beginning of the line, but FETCH_BYTE (bpos) after a dec_both returns
> the same character that the first loop ended on.

No, it doesn't, it returns the byte at bpos after decrementing bpos.
So it's the character before that.

> In other words, start and bpos are not in sync

??? FETCH_BYTE doesn't change bpos, so if it was in sync with start
before FETCH_BYTE, it is still in sync after it.  So I don't think I
understand what you mean here.

Can you elaborate on your findings, please?