Re: XEmacs has just (more than) doubled in size
At 06:11 PM 8/23/99 +0900, Stephen J. Turnbull wrote:
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
Well I wrote most of the comments so I'm glad I agree with myself :)
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
Did it flicker without this change? I still see some redisplay wierdness in
my hacked version which has a lot of fixes in. The idea behind the change
is that the window will just get moved rather than unmapped/mapped if
humanely possible. Unfortunately redisplay bites us most of the time since
it quite often clears the old area before drawing the new area. If it works
for you then I'll put it in.
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.
There were no changes since then, so that's good.
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
Hmmn, that's irritating. The widget should not be doing this. I'll see if I
can force it off.
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.
I know about this. I haven't come up with a good solution yet. Your window
in a window would help. There is no obvious hook to hang a frame size
change off so really it should clip - which is problematic ....
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").
I don't understand.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd