bug#13469: 24.2; emacs has a tiny frame, when I embed it in a kmail text field via xembed (--parent-id %w)

[Eli Zaretskii]

> Date: Thu, 21 Mar 2013 11:57:23 +0100
> From: "Arne Babenhauserheide (IMK)" <arne.babenhauserheide@kit.edu>
> CC: "13469@debbugs.gnu.org" <13469@debbugs.gnu.org>, "arne_bab@web.de"
>       <arne_bab@web.de>
> 
> I just found a much easier way to reproduce it:
> 
> Run emacs with --parent-id <random number>

So it looks like something specific to using the XEmbed protocol, I
guess.

> A backtrace after clicking the minibuffer (which triggers a resize)
> looks like this (without menubar):
> 
> Breakpoint 1, change_frame_size (f=f@entry=0x104b4b0,
> newheight=newheight@entry=5, newwidth=newwidth@entry=21,
> pretend=pretend@entry=0, delay=delay@entry=1,
>     safe=safe@entry=0) at dispnew.c:5726
> 5726    in dispnew.c
> (gdb) backtrace
> #0  change_frame_size (f=f@entry=0x104b4b0, newheight=newheight@entry=5,
> newwidth=newwidth@entry=21, pretend=pretend@entry=0,
> delay=delay@entry=1, safe=safe@entry=0)
>     at dispnew.c:5726
> #1  0x00000000004ed1c8 in xg_frame_resized (f=0x104b4b0, pixelwidth=200,
> pixelheight=75) at gtkutil.c:888
> #2  0x00000000004c3056 in handle_one_xevent
> (dpyinfo=dpyinfo@entry=0x101a3f0,
> eventptr=eventptr@entry=0x7fffffffc360, finish=finish@entry=0xaee010
> <current_finish>,
>     hold_quit=0x7fffffffc720) at xterm.c:6813
> #3  0x00000000004c3a34 in event_handler_gdk (gxev=0x7fffffffc360,
> ev=<optimized out>, data=<optimized out>) at xterm.c:5834
> #4  0x00007ffff7543d52 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
> #5  0x00007ffff75454f8 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
> #6  0x00007ffff754557e in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
> #7  0x00007ffff68c0883 in g_main_context_dispatch () from 
> /usr/lib64/libglib-2.0.so.0

This looks like GTK instructed us to resize ourselves to 200x75
pixels, which was quite reasonably translated to 21x5 characters.
Sounds like a good time for some GTK expert (Jan?) to chime in and
help us out.