"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> While this wasn't exactly intentional, identity preservation was a
> kludge with the old implementation that tied down a number of internal
> invariants related to GC we wanted to get rid of.
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
There were several factors. The initial motivation was GC. However,
there were comments (by Ben, I believe) in the code saying that it
should be rewritten in Elisp. (The old code also used pixel-based
The thing about identity preservation pops up first here:
(I.e. before I even committed the rewrite.)
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
The section on window configurations is pretty careful to avoid
mentioning window identities, but it doesn't explicitly deny that IDs
will be preserved.
Sure. Even the new code *sometimes* preserves them.
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.
Without support from the explicit documentation, I would argue that
those assumptions were always unsafe.
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
XEmacs-Beta mailing list