window configurations no longer (since 21.5) include windows ! ?
sperber at deinprogramm.de
Mon Feb 11 15:22:34 EST 2008
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
More information about the XEmacs-Beta