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

[Michael Sperber]

ht at inf.ed.ac.uk (Henry S. Thompson) writes:

> I can see two alternative paths, doubtless there are others:
>
>  1) (Re-)introduce identity preservation into the code.  I haven't
>     looked into this in detail, but a quick look at the code suggests
>     that if we a) included the windows themselves in saved
>     configurations and b) factored most of split-window out into a
>     function with an additional argument, namely the window to use for
>     the new pane, and called _that_ from set-window-configuration, we
>     could do this.  I _think_ all this would require at the C level
>     would be a function which 'revived' a 'dead' window by flipping
>     the relevant bit.

The bit itself isn't enough: You'd just have to overwrite the window
data with what the window-configuration object says.  That introduces
all kinds of invariants I was to glad to be rid of.

>  2) Introduce a new souped-up version of save-window-excursion, call
>     it save-window-bindings for the sake of argument, looks like this:
>
>     (save-window-bindings (symbols. . .)
>        ...)
>
>     where the semantics is as for save-window-excursion, with the
>     additional guarantee that each of the symbols which is bound to a
>     window will be reset if necessary to the new window which
>     corresponds (in the 'restored' configuration) to the (now dead)
>     window it was bound to going in.

I like the general idea.  How about this:

`set-window-configuration/mapping' is like `set-window-configuration',
except it returns an alist mapping old, dead windows to new, live ones.
Similarly for `save-window-excursion/mapping'.  Would that work for you?

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla