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

Andy> At 05:04 PM 8/20/99 +0900, SL Baur wrote: Andy> Now I understand what you mean this is not quite Andy> correct. Tabs are context sensitive. I.e. by default you Andy> will only see other tabs that relate to the buffer you are Andy> currently in. BTW, This is currently defined as "same mode" by default, right? BTW #2. I don't like the way new tabs always get added at the left. I assume by changing the `buffers-tab-selection-function' I can add them at the right? Or alphabetize them if I want? I am not an experienced X programmer, but there seem to be some strange things in the subwindow/widget implementation. First, it looks like the order of XMoveWindow and XMapWindow in the IMAGE_SUBWINDOW branch of x_map_subwindow() in src/glyphs-x.c is wrong (or maybe it doesn't matter?); the XMoveWindow call should come first, otherwise you're asking for flicker. The widget version immediately below looks right. (I presume it's the widget version that gets called for tab controls, so that can't be the problem here.) Second, the (new) function redisplay_unmap_subwindows_except_us() in src/redisplay-output.c seems like it would be the source of all flicker problems. Under X11, you don't want to iterate over the subwindows; you just unmap the window of interest (the tab control widget). This makes all of its subwindows invisible, and the server should stop generating any Expose events (modulo network lag). But if you don't unmap that window, it will keep receiving Expose events as you map and unmap the subwindows (individual tabs, here). Unless you are very careful about throwing away expose events that occur in the top window (tab control widget), you're going to get extreme amounts of flicker. So that function seems to be exactly backwards. What is the child widget in the tab control? Is there one? If the XEmacs text window is reparented to be a child of the tab control widget, the unmap the whole tab widget strategy doesn't work, but that doesn't seem like the right thing to do. Third, as I understand the code, the subwindow of XEmacs seems to be the tab widget itself. But this is probably too direct. For example, the code contains a comment that if the whole subwindow can't be viewed, none of it should be viewable. I don't think that's right; I can easily think of several applications where you might want it to be partially visible. Also, I don't see why XEmacs shouldn't be able to "swallow" (to use the Fvwm term) X windows created by other processes. One (naive) way to help accomplish both of these goals would be to have the subwindow itself be a "shell" window (like window managers use); then overlay the widget on that or reparent the toplevel window of the external process. X11 puts no constraint that the subwindow be smaller than the "shell", but it won't let the subwindow write outside of the "shell". Viola! correct clipping. Of course, as is pointed out in the comments to the new code, there are all kinds of un-XEmacsy aspects here. Eg, you can't put a subwindow glyph into a buffer, really; it has to be part of the frame. It's not clear how you would handle multiple instances of a fractal-plotting program swallowed into an XEmacs buffer, for example. (It probably _could_ be done, but that would be a wizardly hack!) But that's life, I guess---we accept the restriction. -- 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."