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

[Ken Raeburn]

> 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