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

[Aaron Jensen <aaronjensen@gmail.com>]

On Sat, Jan 9, 2021 at 11:44 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> You mean with
>
>   (window-text-pixel-size t t)
>
> right?

Yes, sorry bad copy/paste.

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

I mean unless you call fit-frame-to-buffer-1 passing nil for from and
to, which I believe is the most likely desired behavior for something
like posframe, but I'm not the maintainer of that so I couldn't say
for certain.


> > 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.

Maybe we're just getting hung up on my wording. After
fetch_char_advance, bpos points to the byte of the character after
what was returned from fetch_char_advance. If you then dec_both and
FETCH_BYTE, you will get the same character returned from the last
time fetch_char_advance was called, which was likely not the intent.

> > 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?

Yeah, I was mistaken on that point. They stay in sync. They both
needed to backtrack an extra time. See my patch in the email I sent
right before this one.