|
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 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-598809266Not 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.
[Prev in Thread] | Current Thread | [Next in Thread] |