From: Michael S. <sp...@de...> - 2008-02-11 20:22:46
|
ht...@in... (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 |