[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Mon, 16 Mar 2020 21:51:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]