Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
Matt Tucker <tuck(a)whistlingfish.net> writes:
> I would content that "It's always worked this way" and "This is
the
> correct behavior" are two totally different statements. Why should
> anyone have to muck around with a completely different facility for
> only the _first_ frame? I would say this is a bug. Even if it's a
> very complex bug that would be extremely difficult to resolve, that
> doesn't change the fact that it's a bug.
I wrote/ported the code, and I agree that it's a bug. I'll explain
the background story first, and then give some ideas about the
possible remedies.
...
That doesn't work for the first frame for the obvious reason that
it
is created before `.emacs' is run. I didn't have an obvious solution
to the problem, so I postponed it until later.
Without knowing much about XEmacs internals, its seems to me thats
the problem. Ie. the first frame is created before the .emacs
is run instead of after.
Its not only the background color that misbehaves, but frame resizes
from the .emacs, repositioning, removing toolbars, scrollbars, etc.
My XEmacs frame jumps all over the place during startup, especially
on Windows.
It would seem pretty simple to start XEmacs with the equivalent of
-unmapped, and then have XEmacs add a make-frame after the .emacs
is read.
--
Dan Espen
444 Hoes Lane Room RRC 1C-214 E-mail: dane(a)mk.telcordia.com
Piscataway, NJ 08854 Phone: (732) 699-5570