Re: Slow Redisplay

Jake> Could the slow redisplay be a result of fontification and Jake> lazy-lock? Is there a "best" way of using font-lock for Jake> optimal redisplay performance? I don't think so. The first pass takes a long time if you do a full fontification, but you will get the "fontifying ... syntax ... regexps" message. At other times, I think it's redisplay itself. How fast is the network connection, or is everybody running on their local box? XEmacs is known to get a lot of Expose events, why I'm not sure, but there are compression options you can enable in Xt resources that help a lot. Especially over a slow connection between XEmacs and the server, but on a sufficiently slow/loaded box, the difference can be perceptible even with a local transport for the X connection. However, this optimization, added in 21.4.12, is apparently totally broken on Motif (makes Motif updates horribly slow), and we've arranged to remove it for Motif as of 21.4.14. There is also a known horrible interaction between the basic Motif XmPrimitive widget and the progress gauge which causes indefinite hangs in progress feedback. I think this is also worked around in 21.4.14. Jake> What do you miss if you specify '--with-widgets=no' and Jake> '--with-dialogs=no'? What interfaces changes will I see? As Vin said, --with-widgets=no means the buffers tabs go way, and the progress bar. In customize screens, you'll see somewhat uglier buttons consed up from bitmap tiles instead of real widgets. With the dialogs, I'm not even sure if you lose all of them. There are a couple that have been historically been implemented as carefully configured Emacs frames (like the file selector), and these may still be available even if --with-dialogs=no. -- 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.