From: <ht...@in...> - 2008-01-29 23:24:29
|
The following code behaves differently in 21.4.21 and 21.5.28: (let ((w (selected-window)) (c (current-window-configuration))) (split-window) (view-buffer-other-window "foo") (delete-window w) (set-window-configuration c) (window-live-p w)) Paste the above into *scratch* and execute it -- value is t in 21.4.21 and nil in 21.5.28. Basically, window identity is not preserved in configurations, or, therefore, by save-window-excursion. This causes no end of trouble for ecb. The following excerpt from the section 38.1 of the Lispref documentation ("Basic Concepts of Emacs Windows") suggests this is an unintended regression: Once removed from the frame, the window is effectively deleted and should not be used, _even though there may still be references to it_ from other Lisp objects. Restoring a saved window configuration is the only way for a window no longer on the screen to come back to life. Can anyone involved in replacing the old C implementation of window configurations (which did save the window objects themselves, along with their properties) with the new Lisp implementation (which does _not_ save the window objects) explain the reasoning behind this incompatible (and as far as I can tell by searching pretty hard, undocumented) change? Thanks, 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...@in... URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] |
From: Stephen J. T. <st...@xe...> - 2008-01-30 22:34:53
|
Henry S. Thompson writes: > The following code behaves differently in 21.4.21 and 21.5.28: > > (let ((w (selected-window)) > (c (current-window-configuration))) > (split-window) > (view-buffer-other-window "foo") > (delete-window w) > (set-window-configuration c) > (window-live-p w)) > > Paste the above into *scratch* and execute it -- value is t in 21.4.21 > and nil in 21.5.28. Basically, window identity is not preserved in > configurations, or, therefore, by save-window-excursion. This > causes no end of trouble for ecb. 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. |
From: Michael S. <sp...@de...> - 2008-02-10 16:57:11
|
ht...@in... (Henry S. Thompson) writes: > The following code behaves differently in 21.4.21 and 21.5.28: > > (let ((w (selected-window)) > (c (current-window-configuration))) > (split-window) > (view-buffer-other-window "foo") > (delete-window w) > (set-window-configuration c) > (window-live-p w)) > > Paste the above into *scratch* and execute it -- value is t in 21.4.21 > and nil in 21.5.28. Basically, window identity is not preserved in > configurations, or, therefore, by save-window-excursion. This > causes no end of trouble for ecb. 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. As the new implementation is in Elisp, identity preservation essentially isn't possible anymore without restoring the old kludges we wanted to get rid of in the first place. Identity preservation was (to my knowledge) never documented, which is why I assumed ditching it would be OK. I did a review of the existing package code at the time to make sure the existing code would continue working. So my recommendation is to try to get rid of the reliance on identity preservation. Sorry for not being more helpful :-( -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla |
From: Stephen J. T. <st...@xe...> - 2008-02-10 23:30:25
|
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 of C. > Identity preservation was (to my knowledge) never documented, 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. > which is why I assumed ditching it would be OK. Aargh! Et tu, Mike? |
From: Michael S. <sp...@de...> - 2008-02-11 06:29:26
|
"Stephen J. Turnbull" <st...@xe...> 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 > of C. 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 dimensions.) The thing about identity preservation pops up first here: http://osdir.com/ml/emacs.xemacs.patches/2002-11/msg00099.html (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 > 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. 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 |
From: <ht...@in...> - 2008-02-11 10:22:40
|
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...@in... URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] |
From: Stephen J. T. <st...@xe...> - 2008-02-11 19:36:14
|
Henry S. Thompson writes: > 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? How does ECB use window identities? What is the "real functionality"? ("In 25 words or less" :-), I'm looking for a design pattern, not a detailed internals document.) |
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 |
From: Michael S. <sp...@de...> - 2008-03-05 08:37:25
|
Hi Henry, did you have a chance to consider this? Michael Sperber <sp...@de...> writes: > 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 |
From: <ht...@in...> - 2008-03-10 15:26:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Sperber writes: > did you have a chance to consider this? > > Michael Sperber <sp...@de...> writes: > >> 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? 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...@in... URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFH1VMlkjnJixAXWBoRAugYAJ9T6HE/vmrP4mIBWgrRuxKzcktXsACfXvX+ HumOE73CBCVPYD8VaRTt3Ss= =E7f7 -----END PGP SIGNATURE----- |
From: Stephen J. T. <st...@xe...> - 2008-02-11 11:37:31
|
Michael Sperber writes: > The thing about identity preservation pops up first here: > http://osdir.com/ml/emacs.xemacs.patches/2002-11/msg00099.html 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. > Without support from the explicit documentation, I would argue that > those assumptions were always unsafe. 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. |
From: Stephen J. T. <st...@xe...> - 2008-02-11 21:06:45
|
Sorry about the tone, I was tired; I should have saved the draft and edited it before sending. Let me gloss it a bit. Stephen J. Turnbull writes: > Michael Sperber writes: > > > The thing about identity preservation pops up first here: > > > http://osdir.com/ml/emacs.xemacs.patches/2002-11/msg00099.html > > Yikes! Man, that's evil. Totally counter-intuitive. "We had to > destroy the window to save it." All that just to move window-point?!? This really is the point. That snippet of code really does just move window-point AFAICS. ISTM IMNSEO that what we really want is that commands that affect the display of a buffer while moving point, and take (or should take) a buffer arg could take a buffer-or-window arg instead. Eg, `goto-char'. The semantics would be that if BUFFER-OR-WINDOW is a buffer or nil (meaning the current buffer), the editing point is moved. If BUFFER-OR-WINDOW is a window, the window-point is moved. As usual, if BUFFER-OR-WINDOW is the selected window or its buffer, then both point and window-point are moved to the same place. I wonder if it might not be a useful extension to expose an `insert-in' primitive which takes a required BUFFER-OR-WINDOW argument (could be nil for current buffer), and inserts text at point in the appropriate buffer. Or even an insert-at which takes required arguments BUFFER-OR-WINDOW and POSITION. Where this little fantasy is going is clear, I think. A "window" becomes a particularly heavyweight kind of marker, which not only points to a particular position in a buffer, but also provides a way to remember display geometry that can be popped up on screen. This seems to correspond to the way most programs that explicitly use Emacs windows use them. To the extent that current windows are somehow too heavyweight for this role, we could pare down the stuff that's required to be present in a window, and provide an "extension record" like the one extents have. This would contain information that is only useful to cache while the window is actually onscreen. Then you could free or gc all the junk there whenever a window is deleted from the frame. One things that really bothers me about all this is that in a galaxy long long ago and far far away, we had a simple architecture of editor objects (buffers) and display objects (windows). This has since grown an awful lot of hair (frames and indirect buffers) without anybody rethinking them globally. |
From: <kla...@sd...> - 2008-05-09 07:14:23
|
Hi Henry, first of all sorry for the late answer Thanks a lot! But one plea: In the meanwhile i have slightly modified ECB. So could you please install latest version 2.33beta2 (either from CVS of via tar-snapshot from the ECB-website) and check if your patches to fix the XEmacs 21.5-problems are still working? This would be a great help for me. If you do not want checkout the complete ECB-CVS then you could easily install latest version via snapshot: Just go to http://ecb.sourceforge.net/ and section "Downloads" and you will see "Latest CVS-shapshot" - just download it and extract the archive and run new ECB... Ciao, Klaus Henry S. Thompson wrote: > [resending after correcting address typo] >> To: Michael Sperber <sp...@de...> >> Cc: "Stephen J. Turnbull" <st...@xe...>, >> xemacs-beta <xem...@xe...>, > > 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 |