On Fri, 4 Oct 2024 at 18:21, martin rudalics <rudalics@gmx.at> wrote:

>  > Looks correct. Unlike some previous situations, where there were
> oddities
>  > (e.g. the frame was wider than the Emacs window, or the minibuf was cut
> off
>  > at the bottom), the frame seems to fit the contents perfectly.
>
> Somewhere these 12 pixels must show up.  What does
>
> (window-pixel-height)
>
> in the *scratch* window evaluate to?
>

(This is for first frame without menu bar.)

(window-pixel-height) ⇒ 1257

I can only suspect that this comes from a request to move the frame that
> doesn't show up in the history.  Now the only location where this might
> happen is in xterm.c around like 29259 here:
>
>         if (original_left != x || original_top != y)
>           XMoveWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
>                        original_left, original_top);
>
> Please put a breakpoint on that line and tell me whether it gets hit.
> The probability is less than 1% but who knows ...
>

Nope, sorry, I put a breakpoint and it was not hit. Indeed, the whole block
starting at 29233 was not hit (I put a breakpoint at the call to
block_input on line 29245).

All line numbers above with your most recent patch gtktutil-frame.diff
applied to commit 4c7a6dc1a0c

-- 
https://rrt.sc3d.org