emacs-devel
[Top][All Lists]
Advanced

[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: martin rudalics
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Fri, 13 Mar 2020 18:46:19 +0100

> 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.

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.

> 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.  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.

martin

Attachment: x-gtk-resize-child-frames.diff
Description: Text Data


reply via email to

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