Re: window configurations no longer (since 21.5) include windows ! ?
ht(a)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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta