Henry S. Thompson writes: I'm pretty sure this is unintentional. Mike Sperber -- mike at xemacs dot org -- did the work, if you don't see a reply from him shortly you may want to ping him. He's definitely active at the moment. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: Where is this documented? To the best of my knowledge the window configuration refactoring just plopped down on XEmacs Patches one day with no design documentation, and I don't recall ever hearing that it was related to GC. I always thought it was about moving to modern pixel-based dimensions and getting non-performance-critical code out of C. I guess you missed this passage from the XEmacs Lisp manual: 38.3 Deleting Windows ===================== A window remains visible on its frame unless you "delete" it by calling certain functions that delete windows. A deleted window cannot appear on the screen, but continues to exist as a Lisp object until there are no references to it. There is no way to cancel the deletion of a window aside from restoring a saved window configuration (*note Window Configurations::). Restoring a window configuration also deletes any windows that aren't part of that configuration. The section on window configurations is pretty careful to avoid mentioning window identities, but it doesn't explicitly deny that IDs will be preserved. Also, anybody with expertise in X11 (and maybe Windwoes and Carbon/Cocoa) would assume that windows can be withdrawn and restored without losing their identities. Aargh! Et tu, Mike? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

My reading of the documentation goes with Stephen's, but that's pretty much beside the point, I guess, although it's also clear that at least one substantial application, namely ecb, depends on identity preservation. The substantive question is: what's the real functionality that is lost when identity preservation is lost, and can we get it back w/o losing the major benefits of the 21.5 promotion of much of the window code from C to elisp? 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. 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. This would also require adding windows themselves to saved configurations, but no changes at the C level. Neither of these is perfect, this is just intended to get some discussion started. (1) has the flaw that it exposes entry points which will have unpredictable and probably catastrophic effects if used in other than the context for which they are intended. (2) has the flaw that it will only repair variable bindings and not, for example, windows held in lists or vectors. . . Thoughts? ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

ht(a)inf.ed.ac.uk (Henry S. Thompson) writes: 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. 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Sperber writes: Yes, sorry, been busy with other things. I've hacked together an implementation of your suggestion, and am just looking to see how/whether I can deploy it to solve the ecb problems. Will report back with more details soon. ht - -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Here's the patch for ecb which, when added to the xemacs-21.5 patch I sent earlier, will get ecb working under 21.5 (and should do no harm wrt previous versions/emacs). ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: Yikes! Man, that's evil. Totally counter-intuitive. "We had to destroy the window to save it." All that just to move window-point?!? Mike, this seriously needs rethinking. It's just not reasonable to invalidate window IDs across save-window-excursion under current ways of thinking. I agree that the `(setq outwin (display-buffer outbuf))' idiom is probably going to be available most of the time but it's ugly, and it's not obvious that such idioms will always work. I'm not even sure why it's supposed to work in this case: it seems obscure. I wish our documentation were that good. I also think that in the absence of an explicit disclaimer (eg. `delete-extent''s docstring says "The extent cannot be used thereafter"), a user may reasonably expect that a Lisp object won't spontaneously become meaningless. Anyway, IMO Section 38.3 as quoted is sufficiently explicit. Windows are persistent objects and they can be revived. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta