window configurations no longer (since 21.5) include windows ! ?

[Henry S. Thompson]

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: [phone], e-mail: ht@...
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Stephen J. Turnbull]

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.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Michael Sperber-2]

ht@... (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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Stephen J. Turnbull]

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?




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Michael Sperber-2]

"Stephen J. Turnbull" <stephen@...> 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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Henry S. Thompson]

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: [phone], e-mail: ht@...
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Stephen J. Turnbull]

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.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Stephen J. Turnbull]

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.)


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Michael Sperber-2]

ht@... (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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Stephen J. Turnbull]

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.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Michael Sperber-2]

Hi Henry,

did you have a chance to consider this?

Michael Sperber <sperber@...> 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

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Henry S. Thompson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Sperber writes:

> did you have a chance to consider this?
>
> Michael Sperber <sperber@...> 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: [phone], e-mail: ht@...
                   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-----

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Henry S. Thompson]

Michael Sperber writes:

>> `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?

The attached patch
 a) implements your suggestion;
 b) enables ecb to work.

So, I guess if the decision is final to abandon preserving window
identity over calls to save-window-excursion, we should go with this.

Of course I don't mind whether you use this code or do your own
version, but note that the first diff is crucial, otherwise user
advice can screw everything.

ht


*** /usr/local/src/xemacs-21.5.28/lisp/window-xemacs.el Tue Oct 31 09:16:29 2006
--- ./window-xemacs.el Sun Mar 16 09:40:36 2008
***************
*** 35,40 ****
--- 35,51 ----
 
  ;;; Code:
 
+ ;; Protect two crucial functions from the impact of advice
+ ;; (Any others need to be treated similarly?)
+ ;; ht@... Sun Mar 16 09:27:35 2008
+
+ (unless (fboundp 'orig-split-window)
+   (fset 'orig-split-window (symbol-function 'split-window)))
+
+ (unless (fboundp 'orig-delete-window)
+   (fset 'orig-delete-window (symbol-function 'delete-window)))
+
+
  (defgroup windows nil
    "Windows within a frame."
    :group 'environment)
***************
*** 124,130 ****
    pixel-left pixel-top pixel-right pixel-bottom
    hscroll modeline-hscroll
    dedicatedp
!   first-hchild first-vchild next-child)
 
  (defstruct window-configuration
    frame
--- 135,142 ----
    pixel-left pixel-top pixel-right pixel-bottom
    hscroll modeline-hscroll
    dedicatedp
!   first-hchild first-vchild next-child
!   window)
 
  (defstruct window-configuration
    frame
***************
*** 256,261 ****
--- 268,274 ----
   (bottom (nth 3 edges)))
        (let ((saved-window
      (make-saved-window
+      :window window
       :currentp (eq window (selected-window (window-frame window)))
       :minibufferp (eq window (minibuffer-window (window-frame window)))
       :minibuffer-scrollp (eq window minibuffer-scroll-window)
***************
*** 287,296 ****
--- 300,334 ----
     (copy-marker (mark-marker t buffer)))))
  saved-window))))
 
+ (defmacro save-window-excursion/mapping (&rest body)
+   "Execute BODY, preserving window sizes and contents.
+ Restores which buffer appears in which window, where display starts,
+ as well as the current buffer.
+ Does not restore the value of point in current buffer.
+ On non-error return, value is cons of BODY value and list of
+ remapped windows (see set-window-configuration/mapping for
+ more on remapping)."
+   (let ((window-config (gensym 'window-config))
+ (res (gensym 'res)))
+     `(let ((,window-config (current-window-configuration))
+   ,res)
+       (unwind-protect
+  (setq ,res (progn ,@body))
+ (setq ,res (cons ,res (set-window-configuration/mapping ,window-config))))
+       ,res)))
+
  (defun set-window-configuration (configuration)
    "Set the configuration of windows and buffers as specified by CONFIGURATION.
  CONFIGURATION must be a value previously returned
  by `current-window-configuration'."
+   (set-window-configuration/mapping configuration)
+   nil)    
+
+ (defun set-window-configuration/mapping (configuration)
+   "As set-window-configuration, but returns an a-list mapping
+ dead windows to their replacements.  This allows you to work
+ around the fact that s-w-c no longer (as of xemacs 21.5) preserves
+ window identity."
    (let ((frame (window-configuration-frame configuration)))
      (if (and (frame-live-p frame)
      (not (window-configuration-equal configuration
***************
*** 298,304 ****
  (really-set-window-configuration frame configuration))))
 
  (defun really-set-window-configuration (frame configuration)
!   "Set the window configuration CONFIGURATION on live frame FRAME."
    ;; avoid potential temporary problems
    (setq window-min-width 0)
    (setq window-min-height 0)
--- 336,343 ----
  (really-set-window-configuration frame configuration))))
 
  (defun really-set-window-configuration (frame configuration)
!   "Set the window configuration CONFIGURATION on live frame FRAME.
! Value is a-list mapping dead windows to their replacements."
    ;; avoid potential temporary problems
    (setq window-min-width 0)
    (setq window-min-height 0)
***************
*** 318,324 ****
            (set-frame-property frame 'top top))))
 
    ;; these may have changed because of the delete
!   (let ((root-window (frame-root-window frame)))
      (enlarge-window-pixels
       (- (window-configuration-minibuffer-pixel-height configuration)
  (window-pixel-height (minibuffer-window frame)))
--- 357,364 ----
            (set-frame-property frame 'top top))))
 
    ;; these may have changed because of the delete
!   (let ((root-window (frame-root-window frame))
! rsw-res)
      (enlarge-window-pixels
       (- (window-configuration-minibuffer-pixel-height configuration)
  (window-pixel-height (minibuffer-window frame)))
***************
*** 336,342 ****
     (window-configuration-saved-root-window configuration)
     'vertical)
        (if window-configuration-current-window
!  (select-window window-configuration-current-window))))
 
    (setq window-min-width (window-configuration-min-width configuration))
    (setq window-min-height (window-configuration-min-height configuration))
--- 376,382 ----
     (window-configuration-saved-root-window configuration)
     'vertical)
        (if window-configuration-current-window
!  (select-window window-configuration-current-window)))
 
      (setq window-min-width (window-configuration-min-width configuration))
      (setq window-min-height (window-configuration-min-height configuration))
***************
*** 344,350 ****
    (let ((buffer (window-configuration-current-buffer configuration)))
      (if (buffer-live-p buffer)
  (set-buffer buffer)
! (set-buffer (car (buffer-list))))))
 
  (defun set-window-configuration-frame-size (configuration)
    "Restore the frame size of a window configuration."
--- 384,391 ----
      (let ((buffer (window-configuration-current-buffer configuration)))
        (if (buffer-live-p buffer)
   (set-buffer buffer)
! (set-buffer (car (buffer-list)))))
!     rsw-res))
 
  (defun set-window-configuration-frame-size (configuration)
    "Restore the frame size of a window configuration."
***************
*** 370,376 ****
      (while window
        (if (window-live-p window)
   (let ((next (window-next-child window)))
!    (delete-window window)
     (setq window next)))))
    (cond
     ((window-first-hchild window)
--- 411,417 ----
      (while window
        (if (window-live-p window)
   (let ((next (window-next-child window)))
!    (orig-delete-window window)
     (setq window next)))))
    (cond
     ((window-first-hchild window)
***************
*** 384,392 ****
         (not (saved-window-minibufferp (saved-window-next-child saved-window)))
         (progn
  (cond ((eq direction 'vertical)
! (split-window window nil nil))
        ((eq direction 'horizontal)
! (split-window window nil t)))
  (restore-saved-window configuration
        (window-next-child window)
        (saved-window-next-child saved-window)
--- 425,433 ----
  (not (saved-window-minibufferp (saved-window-next-child saved-window)))
  (progn
    (cond ((eq direction 'vertical)
!  (orig-split-window window nil nil))
  ((eq direction 'horizontal)
!  (orig-split-window window nil t)))
    (restore-saved-window configuration
  (window-next-child window)
  (saved-window-next-child saved-window)
***************
*** 402,408 ****
     window
     (saved-window-first-vchild saved-window)
     'vertical))
!
    (if (not (saved-window-minibufferp saved-window))
        (restore-saved-window-parameters configuration window saved-window)))
 
--- 443,451 ----
       window
       (saved-window-first-vchild saved-window)
       'vertical))
!     (if (not (eq window (saved-window-window saved-window)))
!       (setq rsw-res (cons (cons (saved-window-window saved-window) window)
!  rsw-res)))
      (if (not (saved-window-minibufferp saved-window))
  (restore-saved-window-parameters configuration window saved-window)))
 
***************
*** 933,939 ****
     split-width-threshold)
  (and (window-leftmost-p window)
      (window-rightmost-p window))))
!       (setq window (split-window window))
      (let (upper other)
        (setq window (get-lru-window target-frame))
        ;; If the LRU window is selected, and big enough,
--- 976,982 ----
     split-width-threshold)
  (and (window-leftmost-p window)
      (window-rightmost-p window))))
!       (setq window (orig-split-window window))
      (let (upper other)
        (setq window (get-lru-window target-frame))
        ;; If the LRU window is selected, and big enough,
***************
*** 945,951 ****
     (not (window-parent window)))
  (>= (window-height window)
     (* 2 window-min-height)))
!   (setq window (split-window window)))
        ;; If get-lru-window returned nil, try other approaches.
        ;; Try visible frames first.
        (or window
--- 988,994 ----
     (not (window-parent window)))
  (>= (window-height window)
     (* 2 window-min-height)))
!   (setq window (orig-split-window window)))
        ;; If get-lru-window returned nil, try other approaches.
        ;; Try visible frames first.
        (or window


--
 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: [phone], e-mail: ht@...
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecb-list mailing list
Ecb-list@...
https://lists.sourceforge.net/lists/listinfo/ecb-list

[Henry S. Thompson]

[resending after correcting address typo]
> To: Michael Sperber <sperber@...>
> Cc: "Stephen J. Turnbull" <stephen@...>,
>  xemacs-beta <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


Index: ecb-layout.el
===================================================================
RCS file: /cvsroot/ecb/ecb/ecb-layout.el,v
retrieving revision 1.257
diff -b -w -C3 -r1.257 ecb-layout.el
*** ecb-layout.el 8 Jul 2007 16:42:05 -0000 1.257
--- ecb-layout.el 16 Mar 2008 14:33:15 -0000
***************
*** 1565,1570 ****
--- 1565,1579 ----
       ;; `ecb-enlarged-compilation-window-max-height'
       (ecb-set-compile-window-height)))
       
+
+  ;; if set-window-configuration changes the values of ecb-edit-window or ecb-compile-window, fix them
+  (defadvice set-window-configuration/mapping (after hack activate)
+    (let ((edit-window-changed (assq ecb-edit-window ad-return-value))
+ (compile-window-changed (assq ecb-compile-window ad-return-value)))
+      (if edit-window-changed
+ (setq ecb-edit-window (cdr edit-window-changed)))
+      (if compile-window-changed
+ (setq ecb-compile-window (cdr compile-window-changed)))))
   ) ;; end of if-ecb-running-xemacs
 
  (when-ecb-running-emacs
Index: ecb-util.el
===================================================================
RCS file: /cvsroot/ecb/ecb/ecb-util.el,v
retrieving revision 1.139
diff -b -w -C3 -r1.139 ecb-util.el
*** ecb-util.el 8 Jul 2007 16:42:04 -0000 1.139
--- ecb-util.el 16 Mar 2008 14:33:26 -0000
***************
*** 1844,1852 ****
            (error "Window must be on frame."))
        (let ((current-frame (selected-frame))
              (current-point (point))
              list)
          (unwind-protect
!             (save-window-excursion
                (select-frame frame)
                ;; this is needed for correct start-point
                (select-window window)
--- 1844,1853 ----
            (error "Window must be on frame."))
        (let ((current-frame (selected-frame))
              (current-point (point))
+    (current-window (selected-window))
              list)
          (unwind-protect
!             (progn ;save-window-excursion
                (select-frame frame)
                ;; this is needed for correct start-point
                (select-window window)
***************
*** 1861,1866 ****
--- 1862,1868 ----
                (setq list (nreverse list))
                (setq list (cons window list)))
            (select-frame current-frame)
+  (select-window current-window)
            ;; we must reset the point of the buffer which was current at call-time
            ;; of this function
            (goto-char current-point))))))


--
 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: [phone], e-mail: ht@...
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.