adding tests to redisplay
Stephen J. Turnbull
stephen at xemacs.org
Sat Mar 28 02:52:37 EDT 2009
Aidan Kehoe writes:
> (Unfortunately, it seems you might have to fight with the -batch-handling
> code to allow tests run with -batch to create GUI frames;
I think this should be avoided. Rather, for the moment we should run
the GUI tests in a separate suite. I already do this in my release
process (all I do is make sure that a window pops up on the release
generating machine, but it's rather embarrassing to release something
that doesn't at least do that ;-).
My rationale is that historically, XEmacs created a frame and started
hanging stuff off that, including X resources and so on. We've
gradually gotten that under control, and now (+== a couple of years
ago) Mike Sperber thinks that it is probably possible to avoid -batch
handling entirely, and simply have something like a --no-initial-frame
(ie, like GNU's emacs-server setup) switch that just postponed
initialization of a connection to an X server until the user asks for
a frame. But that work isn't complete, and if Ram wants to focus on
tests, doing that work is not his job.
OTOH, emacs-server == turn --batch into a switch that does nothing
except reset some "initialize-gui-at-startup" variable is a worthy
task too, if he'd rather do that. Get Mike's advice (cc'd).
Just ... doing both is a rather large mouthful. So keep the tasks
separate unless you consciously decide to do both.
More information about the XEmacs-Beta