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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Sat, 12 Mar 2016 20:21:35 -0500
> Cc: schwab@linux-m68k.org,
>  22975@debbugs.gnu.org
> 
> In X11 mode, both the normal and CANNOT_DUMP versions seem to work fine now, and the cursor motion with C-f in the hello buffer is as you describe.

That's a start.

> In tty mode, the normal version starts fine, and the cursor motion is mostly as you describe, though the Arabic and Hebrew text don’t look the same in the terminal emulator (Mac terminal emulator running ssh to a GNU/Linux box running Emacs) as in the X11 window.  Instead, it looks like, for example, everything after “Hebrew (” on that line is reversed from the X11 display, and the “)” replaced with “(”.  Also, the cursor positioning as I hit C-f or C-b doesn’t quite line up with where the characters are; I think it may be lining up with where it thinks they’d be if they were laid out as in the X11 display.  So it moves over whitespace here, skips a character there…

Can you show a screenshot?

It sounds like your terminal emulator is trying its own reordering of
bidi text.  Can you find some setting to disable that?

In any case, this is unrelated to the issue at hand.

> 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; the second time it’s internal-timer-start-idle, then internal-echo-keystrokes-prefix, and then we just seem to stick with that one from then on.

Please show a full C backtrace from each one of the calls to Fsignal,
so we could see what code calls these functions.

> Obviously the long message lines need to be handled, or at least need to not cause us to error out of the startup.  Maybe C or Lisp could define a simple, dumb version of window--resize-root-window-vertically that gets us past this point?  That might be cheaper than testing on every call to verify that the function has been defined so that we can fall back to some other behavior in this rare case.

Let's defer this discussion till after we see the backtraces.

In general, the above is the price we pay for moving more basic stuff
to Lisp.  But I very much doubt that these problem cannot have some
simple solution.  Whether dumb versions in C are it, I don't know: it
depends on who calls them and what does that code expect from the
call.

> Given how much even basic operation depends on various bits of Lisp code being available, I’m starting to think that if loadup.el cannot load successfully (with the possible exception of site initialization files), maybe Emacs should just refuse to start, instead of continuing on to the top level loop.

No, I don't think so: aborting will remove the error messages and
other phenomena that are needed to debug these problems.

Thanks.