Re: "Final" version of tty child frames

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> I've not yet understood where the third frame is created. Probably have to
>> see this in the debugger to get into this again.
>
> Without really checking it must be here
>
>       /* Use default-minibuffer-frame if possible.  */
>       if (!FRAMEP (KVAR (kb, Vdefault_minibuffer_frame))
>         || ! FRAME_LIVE_P (XFRAME (KVAR (kb, Vdefault_minibuffer_frame))))
>       {
>         Lisp_Object initial_frame;
>
>         /* If there's no minibuffer frame to use, create one.  */
>         initial_frame = call1 (Qmake_initial_minibuffer_frame,
>                                display);
>         kset_default_minibuffer_frame (kb, initial_frame);
>       }
>
> 'default-minibuffer-frame' on ttys is nil, only 'x-create-frame' and the
> like set it AFAICT.  Even if it were some frame, it might be of no use:
> On a tty the mini window to use _must_ be on the visible frame.  So
> Emacs makes a new initial_frame and uses that frame's mini window.  But
> the child frame gets another root frame and sooner or later this will
> crash anyway.  The attached patch fixes it here.

That would have taken me some time to understand :-). 

> martin (who can still post a bug report if you think it's needed)

If that solves everything you reported previously, no bug needed. LGTM.
(Sorry, I'm a bit forgetful when I'm doing something else, and a todo
list doesn't really help, it seems to grow only.)

LGTM, please apply.