bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode

[Eli Zaretskii]

> Date: Sun, 13 Mar 2016 21:09:26 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: raeburn@raeburn.org, 22975@debbugs.gnu.org, schwab@linux-m68k.org
> 
>  >>   > In tty mode, the CANNOT_DUMP version get stuck in a loop at startup
>  >>   > complaining that internal-echo-keystrokes-prefix isn’t defined.  If I
>  >>   > set a breakpoint on Fsignal, it’s first complaining about
>  >>   > window--resize-root-window-vertically when trying to display the long
>  >>   > load path, presumably terminating the processing of loadup.el;
>  >>
>  >> Can you please try adding a placeholder function like Paul did with
>  >> Fframe_windows_min_size and Fwindow__sanitize_window_sizes.
>  >
>  > How can we know what these placeholders should do, without seeing
>  > which code calls them?
> 
> The idea was that if Ken's assumption is right that complaining about
> window--resize-root-window-vertically terminates the processing of
> loadup.el, then such a placeholder function (that would do nothing)
> would have allowed it to proceed ...

But the return value might need to be something specific to steer the
rest of execution where we want it.  For example, grow_mini_window
does this:

  if (delta > 0)
    {
      root = FRAME_ROOT_WINDOW (f);
      r = XWINDOW (root);
      height = call3 (Qwindow_resize_root_window_vertically,
                      root, make_number (- delta), pixelwise ? Qt : Qnil);
      if (INTEGERP (height) && window_resize_check (r, false))
        {
          block_input ();
          window_resize_apply (r, false);

which means we need the placeholder return nil to do what we want.  If
it returns something else, who knows what will happen next?

IOW, we need to study the actual calls to know what to do in the
placeholders.  The same examination could tell us how to avoid the
calls to those functions altogether.  E.g., binding
resize-mini-windows to nil around the code that runs loadup.el would
prevent the call to grow_mini_window in the first place.  Maybe that's
better, I didn't yet make up my mind.