Re: ha ha, only serious

Ray> XEmacs over the same link is a non-starter. An exposure Ray> event (?) Can you be more specific about exactly what you do, and is this 21.5? If it's just _one_ exposure event (eg, cover the frame partially with another window, then close or iconify the covering window), do you see this? (I don't think so, in 21.4, I'll check tonight.) If you are moving a window, even if it's not opaque, _across_ an XEmacs frame you are potentially generating an exposure event for every horizontal or vertical single-pixel movement. (Why we can't handle that gracefully I dunno and it's shameful, but if a single exposure event is causing multiple redraws of the toolbar that's downright _disgusting_.) Ray> causes xemacs to spend about 15 sec redisplaying Ray> the toolbar over and over and over again. Ray> But Lucid emacs with scrollbars and menu worked well enough Ray> over a 9600 bps line way back when. (Thanks Jamie!) I suspect 19.first-version-with-toolbar of XEmacs is OK, too. XEmacs in an X frame is still (subjectively, YMMV) no slower than a TTY frame over the same line for buffer updates as long as there are no exposure events (the last time I tried that with GNU Emacs 21 it was not true). But the widget code seems to have been written under the assumption that redisplay is cheap. :-( -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.