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

[martin rudalics <rudalics@gmx.at>]

 > But I would expect this initial size to be only assigned briefly and
 > then changed (by Emacs, internally, without having been asked) to the
 > dimensions originally specified by the caller. So that the workaround
 > is applied, but the user doesn't really have to see it.

I hoped so too.  But IIUC the child frame must be first mapped with the
large size and even then hiding it once invalidates the workaround: I
must show it again with the large size before I can re-resize it.

 > The child frame could even be made invisible while it's created with
 > this huge size, before it's resized to the target size.

Been there, done that.  I also tried to set the alpha of the child frame
to zero but apparently this won't work for child frames, regardless of
whether they are override-redirect or not.  Can you change transparency
of child frames (to make it 0 you have to set 'frame-alpha-lower-limit'
first)?

 >> (insanely large values can make Emacs even crash here).
 >
 > Seems to be not the issue here.

It should work with a 10000x10000 characters frame.

 > As I describe at the end of this email, the last patch is kinda broken.

Very much so, indeed.  I couldn't try it at that time.

 > I went to the previous version of x-resize-child-frame-special.diff
 > and this time couldn't reproduce this effect (of width often staying
 > unchanged). The problem of "first size changes, then contents" is
 > still there. I also saw occasional graphical glitches and window
 > update problems like the one in the attached screenshot (see the black
 > area; the first line, in blue, should have not have been wrapped in
 > two). Those were hard to reproduce reliably, however.

I see all sorts of glitches.  And I can't guess what goes on underneath.

martin