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

[Dmitry Gutov]

On 13.03.2020 19:46, martin rudalics wrote:
>  > With a custom var, you mean. OK.
>
> I attach the latest diff I made for Emacs 27.  The variable is called
> 'x-gtk-resize-child-frames' and may assume the values 'hide' and
> 'resize-mode' in addition to the default nil.  It should work for Emacs
> 28 as well but it would be important to test it on Emacs 27 for obvious
> reasons.

I've tried the patch, and the behavior is as expected: the value 'hide' 
makes it blink, and 'resize-mode' makes it work correctly.

One unfortunate aspect of making it a custom var is it only works if set 
before the child frame was created. And posframe caches created frames, 
either because child frame creation is expensive, or was such previously.

So if the user sees the problem, searches for a solution, then applies 
it in the current session, they won't see the change. We'll have to say 
"and restart Emacs" in the doc, and hope they won't miss that.

> Clearly, people might want to to set 'x-wait-for-event-timeout' to zero
> as well and we should tell them so.  But here I can't observe that doing
> so has any impact.

It does have impact on my machine.

>  > IIUC though, the majority of the GTK developers work on GNOME and
>  > Mutter as well. If that's the case, asking for Mutter's developers'
>  > help makes sense anyway.
>
> It would make sense but if they don't respond ...
>
>  > I asked that question today. Got one +1 so far: 
> https://github.com/tumashu/company-posframe/issues/2#issuecomment-598809266
>
> Not much so far.

Since then we have another +1 in the issue comments above, as well as an 
additional solid thumbs up on the patch from the first reporter.

> In either case, whenever people report a "it changes
> size somewhat half a second later" then this usually means that a frame
> move occurred on a platform (like GNOME shell) that does not report a
> frame position as Emacs expects it (Bug#38452), does not send a suitable
> event in due time and is thereafter penalized by xterm.c's
>
>    /* As a last resort, just wait 0.5 seconds and hope that XGetGeometry
>       will then return up-to-date position info. */
>
>    wait_reading_process_output (0, 500000000, 0, false, Qnil, NULL, 0);
>
> This should be bypassed by my patch but for non-child frames the delay
> persists.  Users then might want to drop a couple of zeros from that
> insane nanosecond argument.

I've never seen a "half a second" later problem myself, and the person 
who complained says he doesn't see that anymore [for some reason]. So 
maybe we can leave that alone for now.