martin rudalics <rudalics@gmx.at> writes:

>> So when everything kinda works:
> [...]
>> So we start small, go big, then go small again, but the end result,
>> even though it looks correct, is actually wrong:
>>
>> (frame-parameter nil 'height)
>> 36
>> (frame-parameter nil 'width)
>> 80
>>
>> Although I asked for:
>>
>> (add-to-list 'default-frame-alist '(width . 130))
>> (add-to-list 'default-frame-alist '(height . 56))
>>
>> in the .el Iʼm loading.
>
> Isn't "when everything kinda works" the end result "is actually wrong"
> somehow contradictory?  I think you mean to say that the end result is
> consistent but fails to process the values you specified.
>

Yes, which is why I used the modifier 'kinda'. The emacs state is
consistent and usable, but not as requested.

>> When it doesnʼt work:
> [...]
>> we start big, go small, and stay small. The frame is actually the same
>> size as previous, but emacs' state is messed up:
>>
>> (frame-parameter nil 'height)
>> 56
>> (frame-parameter nil 'width)
>> 130
>
> This means that you get the expected values for the parameters but the
> frame itself has the wrong sizes?

Yes, plus parts of emacs obviously believe the frame-parameters, since
the minibuffer and modeline are not visible.

> What did you use to produce this and does it only happen with scaling?
> I still do not understand the nature of this bug in the first place.

src/emacs -q --no-site-file --no-site-lisp --no-splash --eval '(setq
x-wait-for-event-timeout nil)' -l ../emacs-real-26/31745.el

(although it happens with non-nil x-wait-for-event-timeout as well)
where 31745.el is based off the original reporter's .emacs (attached).

Scaling is not in effect.

Regards

Robert