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

[Ken Raeburn <raeburn@raeburn.org>]

> It turns out we already had protection for this: xdisp.c was looking
> at the value of purify-flag to decide when it is safe to perform bidi
> reordering.  That protection was added to fix bug#9963.
> 
> However, a change in Dec 2013 made purify-flag be nil on systems that
> CANNOT_DUMP when they process loadup.el, so that protection was lost
> on those systems.
> 
> I've now added a special variable for this purpose, and changed the
> display engine to use it instead of purify-flag.  Ken, could you
> please see if the latest emacs-25 branch resolves the original problem
> you reported?  If Emacs succeeds to start in tty mode after these
> changes, please type "C-h H" and see if the Arabic and Hebrew
> greetings are displayed correctly reordered (moving cursor with C-f
> across those parts should move right-to-left when point is inside
> those words).

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.

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…

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.

So, at least the abort’s gone; that’s something…. :-)

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.

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.

Ken