bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[martin rudalics]

> The window manager can resize the window, for example when you drag on
> its corners, or when you maximize it.  Or it can intercept Emacs
> resize request and modify it, so it is consistent with size hints.  In
> both cases a ConfigureNotify is sent.  Gtk+ does receive it.

In gtk_window_configure_event?

> The
> problem is that Gtk+ then tries to apply size hints also.

Via gtk_window_move_resize?  Which, in principle, is not entirely wrong.
Emacs gets what it asked for.  Can't we reset the size hints in between?
That's what I earlier meant by "interception".

> Focus events does not contain any information about width/height and
> can't be taken as a resize request.  That would be kind of perverse,
> focus has nothing to do with resize.

Didn't the OP mention that during a focus event a resize also took
place?  That's what he said:

   However, when receiving a FocusIn event (just by cycling focus),
   emacs properly aligns the minibuffer to the bottom, and displays a
   partially-visible line just above the minibuffer (test_after.png).

>> Apparently no such measure is needed for fullheight/-width frames.
>
> The bug report that lead to the change mentioned no such problems.

The OP said that:

   I force the emacs frame to take the height of the entire screen.

So this looks like a fullheight frame to me without, apparently,
explicitly specifying it as such.

> The window manager is what does the fullscreen happen, so it is free
> to ignore any hints, i.e. hints should not matter, fullscreen takes
> precedence.  But in principle hints during fullscreen may not reflect
> the "true" state of affairs.

Maybe the OP's problem is that the Window manager conceptually gives
Emacs the full height of the screen and Gtk+ is not aware of that.
Maybe also Gtk+ doesn't even understand fullheight.  At least I can't
detect an entry for it in GtkWindowPrivate which OTOH has a 'tiled'
entry.

martin