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/