Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Martin,

On 13.02.2020 20:42, martin rudalics wrote:
>  > Just the previous version of the patch with the same filename. The 
> one in this email:
>  >
>  > https://lists.gnu.org/archive/html/emacs-devel/2020-01/msg00971.html
> 
> This one adjusted our windows before issuing the resize request so it
> was cheating, in some sense.  It turned out here that we have to issue a
> gdk_window_resize request instead of a gtk_window_resize request in
> order to have mutter respond at all.  In addition, we have to process
> ConfigureNotify differently.  The attached use_gdk_resize.diff does that
> so you should be able to run a normal 'set-frame-size' and be able to
> resize the child frame within its initial size.  Making the child frame
> sufficiently large initially, the patch can handle all resizes here.
> It's not a feasible solution and breaks redisplay with xfwm4 though.
> 
> I also attach a second patch called hide-child-frame-during-resize.diff
> which does nothing else but hiding a child frame during resizing.  You
> have to toggle 'x-gtk-hide-child-frame-during-resize' to make it work.
> It will cause flicker but is probably the one only thing we could do for
> Emacs 27.

Sounds like posframe could make this work if both patches could be 
pushed to emacs-27, and if they didn't break any other window managers.

(Hiding the child frame during resizing could be used only when resizing 
down from the unreasolable large size, for example).

BTW, are they supposed to be applied on top of current emacs-27? The 
second one fails with:

$ patch -p1 < hide-child-frame-during-resize.diff
patching file src/gtkutil.c
Hunk #2 FAILED at 1002.
Hunk #3 succeeded at 1018 (offset 1 line).
1 out of 3 hunks FAILED -- saving rejects to file src/gtkutil.c.rej
patching file src/xterm.c
Hunk #1 succeeded at 13763 (offset 16 lines).

> Neither of these solutions is practicable so we still have to contact
> the mutter people.  Unfortunately, there are probably a number of
> additional issues as well so in their present form Emacs and mutter are
> not really compatible.

I think we have made out due diligence and studied the problem with some 
detail, and we can write the details out to the Mutter bug report.

Maybe we'll have some luck, and one of the developers replies with a 
simple alternative fix? That happened to me before with other projects.

I won't be holding my breath, of course.