Re: window configurations no longer (since 21.5) include windows ! ?

Sorry about the tone, I was tired; I should have saved the draft and edited it before sending. Let me gloss it a bit. Stephen J. Turnbull writes: This really is the point. That snippet of code really does just move window-point AFAICS. ISTM IMNSEO that what we really want is that commands that affect the display of a buffer while moving point, and take (or should take) a buffer arg could take a buffer-or-window arg instead. Eg, `goto-char'. The semantics would be that if BUFFER-OR-WINDOW is a buffer or nil (meaning the current buffer), the editing point is moved. If BUFFER-OR-WINDOW is a window, the window-point is moved. As usual, if BUFFER-OR-WINDOW is the selected window or its buffer, then both point and window-point are moved to the same place. I wonder if it might not be a useful extension to expose an `insert-in' primitive which takes a required BUFFER-OR-WINDOW argument (could be nil for current buffer), and inserts text at point in the appropriate buffer. Or even an insert-at which takes required arguments BUFFER-OR-WINDOW and POSITION. Where this little fantasy is going is clear, I think. A "window" becomes a particularly heavyweight kind of marker, which not only points to a particular position in a buffer, but also provides a way to remember display geometry that can be popped up on screen. This seems to correspond to the way most programs that explicitly use Emacs windows use them. To the extent that current windows are somehow too heavyweight for this role, we could pare down the stuff that's required to be present in a window, and provide an "extension record" like the one extents have. This would contain information that is only useful to cache while the window is actually onscreen. Then you could free or gc all the junk there whenever a window is deleted from the frame. One things that really bothers me about all this is that in a galaxy long long ago and far far away, we had a simple architecture of editor objects (buffers) and display objects (windows). This has since grown an awful lot of hair (frames and indirect buffers) without anybody rethinking them globally. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta