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

[martin rudalics <rudalics@gmx.at>]

 >> The reason for this (and I don't know if you've seen it as well)
 >
 > Not really. If I drag any border of a normal, decorated frame, the other borders stay where they were.

Did you run this with a pristine, unpatched GTK+ build?  Did you compare
the outer right edges before and after the moves?  Everything here is OK
when running the 'bar' functions from a Lucid build, BTW.

I suppose though that your Emacs' redraws too lag behind by showing
either a gap between the right scroll bar and frame border when dragging
to the left and not showing the scroll bar when dragging to the right?
Here they do that even when dragging the left border with the WM alone.

 > I'm guessing that here, under Mutter, the window manager controls the
 > sizing and positioning when I'm doing this. And Emacs just handles
 > sizing notifications and redraws itself. So I've never seen this
 > particular issue act up in practice.

Then it would ignore the Emacs sizing request even for a top-level frame
something we hadn't that far.  Unless your machine is so fast that you
can handle all requests in "real time" so that you don't see the lags I
mentioned above.

 > But your description sounds similar to my results in the previous experiment with non-decorated non-child frames.
 >
 >> The commands 'foo-' and 'foo+' drag the left border a 100 times to the
 >> right or left by three pixels in one step.  The right border should
 >> remain unchanged.  The commands 'bar-' and 'bar+' should do the same
 >> but, in fact, sometimes move the right border as well.
 >
 > Yes, I'm seeing exactly the same results with these commands (aside from the redisplay detail, which I haven't tried).

You mean the right border never ever moves with the bar functions.
Don't bother for the redisplay and sleep-for details then.  We just see
different bugs with different builds and WMs.  Biodiversity at work.

martin