I run many xemacsen through ssh. Some of the machines I run remote xemacsen on are networkologically far away -- on the other side of both a T1 and a DSL. X traffic tunnelled through ssh this way is understandably slow, but still tolerable. Except when XEmacs is processing exposure events. Then it's a nightmare. Here's what happens: - Have an XEmacs window with the left 50% of the window occluded by some higher window. - Drag that other window away to the left. - The XEmacs window is fully visible on the screen ~2 seconds later. - XEmacs repaints column 39, and flickers a few times. - XEmacs repaints column 38, and flickers a few times. - XEmacs repaints column 37, and flickers a few times. ... - 20 seconds later, I can type at XEmacs again. So clearly there's some bad logic in the event processing here. At the end of second two, XEmacs has dozens of Expose events on its queue. It is processing each of them in turn, probably with an XSync after each, instead of reading them all, then doing one batch refresh that paints all damaged areas. This is my number one most irritating XEmacs bug. I used to (mostly) work around this by turning off OpaqueMove in my window manager, but apparently the version of Sawfish that ships with Red Hat 8 has removed the option to have non-opaque moves, so it just got a lot more irritating. This bug has existed in every version of XEmacs in recent memory. -- Jamie Zawinski jwz(a)jwz.org http://www.jwz.org/ jwz(a)dnalounge.com http://www.dnalounge.com/