Re: Add function to rotate/transpose all windows

[martin rudalics <rudalics@gmx.at>]

 > So maybe this is better:
 >
 >     Dead REFER window was not a leaf window"

OK.

 >>   >> +      else if (!WINDOW_LIVE_P (refer))
 >>   >> +	error ("Reference window must not be internal");
 >>   >
 >>   > Are we sure "internal" here will be understood?  How about using "leaf
 >>   > window" instead?
 >>
 >> But it's the opposite - a "non-leaf window".
 >
 > Yes, so I suggested replacing "must not be internal" with "must be a
 > leaf window".  Is that wrong?

No.  We could also say "must display a buffer".

 >
 >>   >>   	  unchain_marker (XMARKER (w->start));
 >>   >> +	  wset_old_buffer (w, w->contents);
 >>   >
 >>   > What is this about?
 >>
 >> When we make a new window and delete it before redisplay runs
 >> window_change_functions for the first time, the old buffer of the window
 >> is nil.  But that would have caused the "Dead reference window's old
 >> buffer is dead" error with the earlier proposed 'resurrect-window' while
 >> in fact the window (made by 'split-window' right before) did have an old
 >> buffer.  It has no significance for the new 'split-window'.
 >
 > So this fixes a related but different bug?

It wasn't a bug so far because the "old buffer" was not defined for dead
windows.  'window-old-buffer' is described as

   Return the old buffer displayed by WINDOW.
   WINDOW must be a live window and defaults to the selected one.

   The return value is the buffer shown in WINDOW at the last time window
   change functions were run.  It is nil if WINDOW was created after
   that.  It is t if WINDOW has been restored from a window configuration
   after that.

What the patch does is to now make it work for dead windows in the sense
that its value is that of the buffer shown in the window at the time the
window was deleted.  In general, this _is_ the buffer stored in the
old_buffer slot.  But if we manage to delete a window whose old buffer
is nil or t _before_ running window change functions on it for the first
time, it isn't.

But I just noticed that even 'window-old-buffer' can be affected by the
patch if we (i) make a window (ii) delete it before it's seen by the
change functions and (iii) resurrect it.  In that (unlikely) scenario
the next change functions will consider the window as one seen by the
last change functions although these have never seen it.  I have to add
another slot del_buffer to the window structure.

martin