Re: XEmacs has just (more than) doubled in size

Sorry for not doing a little more homework first: Stephen> Second, the (new) function Stephen> redisplay_unmap_subwindows_except_us() in Stephen> src/redisplay-output.c seems like it would be the source Stephen> of all flicker problems. Under X11, you don't want to Stephen> iterate over the subwindows; you just unmap the window of Stephen> interest (the tab control widget). I now see that I'm confused by the overloading of the term "subwindow"; I think of it in terms of its windowing system definition (and generalize that to descendants, not just children); but Andy (and the comments in the code) just means a subwindow "glyph" as instanced by XEmacs, and not (for example) individual tabs which are subwindows of the tab control widget. So the current code does not explicitly unmap children of glyph/subwindows. I still think that it wrong to leave the subwindow itself mapped; I have replaced the call to redisplay_unmap_subwindows_except_us() with a call to redisplay_unmap_subwindows() with no perceptible flickering (FWIW; this particular version of 2.1.19 did not show any flickering with the CVS code "as was" on 20 Aug 3pm JST -0900). This version also (limited testing) seems to be gathering all buffers in the same mode together as specified. One new (to me) problem is that when the space required by the tabs exceeds the width of the frame, two rows of tabs are created, whose visibility depends on the currently selected buffer in an annoying way (the currently selected buffer's tab row is not visible, even if the visible row contains only one tab). Another problem (continuing from 21.2.18-plus IIRC, my first tab-enabled XEmacs) is that if the frame is resized smaller, the tab control disappears from the gutter and doesn't reappear through typical refresh operations until the buffer-window mapping is changed. If two frames are displaying buffers in the same mode, there are interactions between the buffer displayed in one and the list of tabs for the other, at least if the tab control is too wide for the second (no input via keyboard or mouse) frame. This seems to be associated with the other frame getting raised (I don't call that "input"). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."