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

[Stephen J. Turnbull]

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:

 > Michael Sperber writes:
 > 
 >  > The thing about identity preservation pops up first here:
 > 
 >  > http://osdir.com/ml/emacs.xemacs.patches/2002-11/msg00099.html
 > 
 > Yikes!  Man, that's evil.  Totally counter-intuitive.  "We had to
 > destroy the window to save it."  All that just to move window-point?!?

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.