Re: how could the mighty emacs lack --fullscreen ?

[Richard Stallman]

    OK, now I understand the question.  My thought was that the splash 
    screen is a separate window, that isn't editable, resizable or possible 
    to customize in any greater extent (if at all).  It just contains enough 
    space to show the image and one or two lines of text.  What I call the 
    initial frame is mapped after the splash screen goes away, which is 
    after .emacs has been read.

Indeed, that is the difference.  The question is, why is one
less "jumpy" than the other?  Both involve a jump.

Perhaps the obviously-intentional jump from the splash screen to the
real frame seems less "wrong" than the smaller jump from the initial
screen parameters to the ultimate ones.  Also, it could be a way to
eliminate some current bugs where the ultimate position or size is
wrong.

But there is another question: where would error messages, questions,
etc. appear during the reading of the init files if there is only a
splash frame?

Perhaps the splash frame could be a real Emacs frame, just very
different in its position and contents from the intended one.  What do
people think of that?

    Would it be possible to start emacs minimized and "restore" the frame
    as the last startup step (after .emacs has been read) ?

This has some advantages.  One is that Emacs could deiconify the frame
at any time if it needs to (.emacs asks a question, say).  It will
also seem a natural form of continuity.  One drawback is that (with
many modern window managers) nothing will appear on the screen to indicate
the existence of the new frame until it is deiconified.

    Instead of updating .Xdefaults, it would be better to have a
    separate file (.emacs.Xdefaults?) and just add it to the other
    X resource sources that Emacs reads.

That is ok.

    The downside is that it probably don't work on all types of window
    systems.  I don't know if MS Windows or Mac has any equivalent to
    .Xdefaults.

Can someone give the answer?