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

[martin rudalics]

> 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