mouse-drag-mode-line should maybe use window-tree

mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

Looking a bit at `mouse-drag-mode-line' I found that it in certain 
window configuration might fail because it does not seem aware of that 
window splitting is two dimensional.

I think it could use the functions in bwcvs.el for vertical moving.

Re: mouse-drag-mode-line should maybe use window-tree

[Richard M. Stallman]

    Looking a bit at `mouse-drag-mode-line' I found that it in certain 
    window configuration might fail because it does not seem aware of that 
    window splitting is two dimensional.

Could you please be more specific?

Re: mouse-drag-mode-line should maybe use window-tree

[Peter Whaite]

Richard M. Stallman <rms@gnu.org> wrote:
>     Looking a bit at `mouse-drag-mode-line' I found that it in certain 
>     window configuration might fail because it does not seem aware of that 
>     window splitting is two dimensional.
> 
> Could you please be more specific?

Missed the beginning of this but I have noticed a problem when using
ECB (which is very nice BTW).  When the frame is split like this

            +----+------------+
	    |    |            |
	    +====+            |
            |    |            |
            |    *============+   ==== - modeline
            +====+            |
            |    |            |
            +====+            |
            |    |            |
            +====o============+

I find I can only move the vertical split to the left or right by
dragging on the left end of the center-right modeline (at * above).  The
cursor does change to <=> when hovering over the left end of the
bottom-right modeline (at o above), but trying to drag with mouse-1 has
no effect.

I guess it makes sense politically.  The left of the center-right has
always been more amenable to change than anything in the bottom-right.


-- 
Peter Whaite

Re: mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

Richard M. Stallman wrote:

>    Looking a bit at `mouse-drag-mode-line' I found that it in certain 
>    window configuration might fail because it does not seem aware of that 
>    window splitting is two dimensional.
>
>Could you please be more specific?
>
Sorry, forgot to write that it is the code in `mouse-drag-window-above' 
that looks suspicious to me. It seems like it only compares the top of 
the parameter window with the bottom of other windows. Maybe that could 
fail, I am not sure. If the code is correct it must depend on the order 
in which `previous-window' returns the windows.

I have not however been able to find a window configuration where it 
fails so I guess that the code is correct. But maybe it deserves a 
comment in `mouse-drag-window-above'?

Re: mouse-drag-mode-line should maybe use window-tree

[Richard M. Stallman]

    Sorry, forgot to write that it is the code in `mouse-drag-window-above' 
    that looks suspicious to me. It seems like it only compares the top of 
    the parameter window with the bottom of other windows.

Yes, it is finding a window whose bottom is at the same height
as the top of this one.

Are you saying it might find the wrong window?  It could find a window
that ends at the same vertical position as the right window, but is
located to the side of it?

I am not sure if that bug can occur.  Can you add code to
verify that the window found overlaps in the horizontal dimension
with the given window?

Re: mouse-drag-mode-line should maybe use window-tree

[Richard M. Stallman]

    I find I can only move the vertical split to the left or right by
    dragging on the left end of the center-right modeline (at * above).  The
    cursor does change to <=> when hovering over the left end of the
    bottom-right modeline (at o above), but trying to drag with mouse-1 has
    no effect.

I just added a function adjust-window-trailing-edge
which should make it easy to fix this bug.  We just have to change
the Lisp code for sideways dragging.  Where is that?

Re: mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

Richard M. Stallman wrote:

>    Sorry, forgot to write that it is the code in `mouse-drag-window-above' 
>    that looks suspicious to me. It seems like it only compares the top of 
>    the parameter window with the bottom of other windows.
>
>Yes, it is finding a window whose bottom is at the same height
>as the top of this one.
>
>Are you saying it might find the wrong window?  It could find a window
>that ends at the same vertical position as the right window, but is
>located to the side of it?
>
>I am not sure if that bug can occur.  Can you add code to
>verify that the window found overlaps in the horizontal dimension
>with the given window?
>  
>
I have attached a patched where I believe I have done that.

[-- Attachment #2: mouse-drag-window-above.patch --]
[-- Type: text/plain, Size: 1921 bytes --]

Index: lisp/mouse.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mouse.el,v
retrieving revision 1.287
diff -c -r1.287 mouse.el
*** lisp/mouse.el	27 Nov 2005 19:28:58 -0000	1.287
--- lisp/mouse.el	28 Nov 2005 23:51:44 -0000
***************
*** 355,368 ****
  (defun mouse-drag-window-above (window)
    "Return the (or a) window directly above WINDOW.
  That means one whose bottom edge is at the same height as WINDOW's top edge."
!   (let ((top (nth 1 (window-edges window)))
  	(start-window window)
  	above-window)
      (setq window (previous-window window 0))
      (while (and (not above-window) (not (eq window start-window)))
!       (if (= (+ (window-height window) (nth 1 (window-edges window)))
! 	     top)
! 	  (setq above-window window))
        (setq window (previous-window window)))
      above-window))
  
--- 355,375 ----
  (defun mouse-drag-window-above (window)
    "Return the (or a) window directly above WINDOW.
  That means one whose bottom edge is at the same height as WINDOW's top edge."
!   (let ((start-top (nth 1 (window-edges window)))
!         (start-left (nth 0 window))
!         (start-right (nth 2 window))
  	(start-window window)
  	above-window)
      (setq window (previous-window window 0))
      (while (and (not above-window) (not (eq window start-window)))
!       (let ((left  (nth 0 (window-edges window)))
!             (right (nth 2 (window-edges window))))
!         (when (and (= (+ (window-height window) (nth 1 (window-edges window)))
!                       start-top)
!                    (or (and (< left start-left)  (< start-right right))
!                        (and (< start-left left)  (< left start-right))
!                        (and (< start-left right) (< right start-right))))
!           (setq above-window window)))
        (setq window (previous-window window)))
      above-window))
  

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

Richard M. Stallman wrote:

>    I find I can only move the vertical split to the left or right by
>    dragging on the left end of the center-right modeline (at * above).  The
>    cursor does change to <=> when hovering over the left end of the
>    bottom-right modeline (at o above), but trying to drag with mouse-1 has
>    no effect.
>
>I just added a function adjust-window-trailing-edge
>which should make it easy to fix this bug.  We just have to change
>the Lisp code for sideways dragging.  Where is that?
>
To me the documentation for `adjust-window-trailing-edge' looks like it 
is doing the same thing as `enlarge-window' with preserve-before set to 
t. Am I missing something?

Re: mouse-drag-mode-line should maybe use window-tree

[Richard M. Stallman]

    To me the documentation for `adjust-window-trailing-edge' looks like it 
    is doing the same thing as `enlarge-window' with preserve-before set to 
    t. Am I missing something?

They are not the same, because adjust-window-trailing-edge will never
delete a window.

I will update the doc of enlarge-window to make it clear that it
can delete windows.

Re: mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

Richard M. Stallman wrote:

>    To me the documentation for `adjust-window-trailing-edge' looks like it 
>    is doing the same thing as `enlarge-window' with preserve-before set to 
>    t. Am I missing something?
>
>They are not the same, because adjust-window-trailing-edge will never
>delete a window.
>  
>
After spending some time wondering why you wrote the new function I 
realized that it was just enough to nicely fit the needs of the resizing 
functions. The new function also seems to work in all cases I have 
tested so far. Thanks for this, it made it much easier to write the new 
functions for balance-windows. I have replaced `enlarge-window' with 
`adjust-window-trailing-edge' everywhere in the new version:

    http://ourcomments.org/Emacs/DL/elisp/test/bwcvs.el

I am stil waiting for someone to test this and give some feedback. 
(There is still a little bit cleanup to do in the code, but I wait with 
this until I have seen that using the new functions have been tested a 
bit more.) So please test this.

A little recall of the proposed new functions:

   C-x +     -- this now starts a new temporary minor mode for resizing, 
bw-window-resize-mode

In this temporary minor mode the keybindings are:

   +        -- new balance-windows, called bw-balance
   .        --  balance siblings only, called bw-balance-siblings
   arrow keys   -- interactive resize, modelled after GUI keyboard 
resize on w32

Re: mouse-drag-mode-line should maybe use window-tree

[Stefan Monnier]

>     To me the documentation for `adjust-window-trailing-edge' looks like it
>     is doing the same thing as `enlarge-window' with preserve-before set to
>     t.  Am I missing something?
> They are not the same, because adjust-window-trailing-edge will never
> delete a window.

Could you explain the choice of identifier?  I have a hard time understanding
what "adjust-window-trailing-edge" can mean.  What's a trailing edge?

Couldn't we just change the `preserve-before' argument (which is new in
Emacs-22 anyway) instead?

AFAIK in all the cases where the `preserve-before' argument is useful, it's
also useful to avoid deleting windows, but if not, we could have 3 values
for `preserve-before', e.g.:
- nil: same as before.
- `nodelete': behave like adjust-window-trailing-edge.
- t: same as above, but can delete windows.


        Stefan

Re: mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

Stefan Monnier wrote:

>>    To me the documentation for `adjust-window-trailing-edge' looks like it
>>    is doing the same thing as `enlarge-window' with preserve-before set to
>>    t.  Am I missing something?
>>They are not the same, because adjust-window-trailing-edge will never
>>delete a window.
>>    
>>
>
>Could you explain the choice of identifier?  I have a hard time understanding
>what "adjust-window-trailing-edge" can mean.  What's a trailing edge?
>  
>
I think it comes from the structure of the window split tree. I believe 
siblings are ordered from top to bottom or from left to right depending 
on the split direction. So trailing edge is the edge at the bottom or at 
the right.

>Couldn't we just change the `preserve-before' argument (which is new in
>Emacs-22 anyway) instead?
>  
>
There is another nice feature of the new function: It takes a window 
argument. That means you do not have to set and reset the selected window.

Re: mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

Lennart Borgman wrote:

> Stefan Monnier wrote:
>
>
>> Couldn't we just change the `preserve-before' argument (which is new in
>> Emacs-22 anyway) instead?
>>  
>>
> There is another nice feature of the new function: It takes a window 
> argument. That means you do not have to set and reset the selected 
> window.

Forgot to mention that the new function Richard wrote works too. There 
is (or at least was) a bug in enlarge-window when the nearest window in 
the enlarge direction was not belonging to the siblings (in the window 
split tree) of the window beeing resized.

Re: mouse-drag-mode-line should maybe use window-tree

[Stefan Monnier]

> There is another nice feature of the new function: It takes a window
> argument.  That means you do not have to set and reset the
> selected window.

`with-selected-window' is not that big a deal, but I see your point.

If we keep adjust-window-trailing-edge then I suggest to remove the
`preserve-before' argument to enlarge-window.


        Stefan

Re: mouse-drag-mode-line should maybe use window-tree

[Richard M. Stallman]

    After spending some time wondering why you wrote the new function I 
    realized that it was just enough to nicely fit the needs of the resizing 
    functions. The new function also seems to work in all cases I have 
    tested so far.

If you're not careful about the order in which you move the edges,
adjust-window-trailing-edge can easily give you an error.  The reason
is that it never moves any edges above or below the one you specify to
move, and it can't make any window too small.

If you're not careful about the order to move the edges,
some intermediate state could easily be invalid, resulting
in an error.

Perhaps your code copes with this issue already.  If not, it needs to.

Re: mouse-drag-mode-line should maybe use window-tree

[Richard M. Stallman]

    Could you explain the choice of identifier?  I have a hard time understanding
    what "adjust-window-trailing-edge" can mean.  What's a trailing edge?

A trailing edge is the bottom or right edge.
Can you think of a better name for that?

    Couldn't we just change the `preserve-before' argument (which is new in
    Emacs-22 anyway) instead?

We could, but note that the new definition would be a cumbersome
combination of meanings:

    Don't move the predecessor windows.
    Don't delete any windows.
    Don't shring non-adjacent windows.

For this meaning, I think it is better to use a different function.
However, maybe we should eliminate the PRESERVE-BEFORE argument now.
It was an attempt at doing what we have now done better; perhaps
we should get rid of it rather than release it.

Re: mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

Richard M. Stallman wrote:

>    After spending some time wondering why you wrote the new function I 
>    realized that it was just enough to nicely fit the needs of the resizing 
>    functions. The new function also seems to work in all cases I have 
>    tested so far.
>
>If you're not careful about the order in which you move the edges,
>adjust-window-trailing-edge can easily give you an error.  The reason
>is that it never moves any edges above or below the one you specify to
>move, and it can't make any window too small.
>
>If you're not careful about the order to move the edges,
>some intermediate state could easily be invalid, resulting
>in an error.
>
>Perhaps your code copes with this issue already.  If not, it needs to.
>  
>
I think it copes with this. For the case of what I have called 
"interactive resize" (with the arrow keys) there are no problems. For 
the case of the new version of balance-windows (which I so far calls 
`bw-balance') I catch the errors and loop. So far I have seen no 
drawbacks with this.

Re: mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

Richard M. Stallman wrote:

>For this meaning, I think it is better to use a different function.
>However, maybe we should eliminate the PRESERVE-BEFORE argument now.
>It was an attempt at doing what we have now done better; perhaps
>we should get rid of it rather than release it.
>  
>
No objections to that, I think I have switched to the new function 
everywhere.

Re: mouse-drag-mode-line should maybe use window-tree

[Richard M. Stallman]

    I think it copes with this. For the case of what I have called 
    "interactive resize" (with the arrow keys) there are no problems. For 
    the case of the new version of balance-windows (which I so far calls 
    `bw-balance') I catch the errors and loop. So far I have seen no 
    drawbacks with this.

That is good.

Could you please install your rewrite of balance-windows?
That is a bug fix we want.  The other command is a new feature
so it should not be installed now.

Re: mouse-drag-mode-line should maybe use window-tree

[Richard M. Stallman]

I deleted the preserve-before arguments.

Re: mouse-drag-mode-line should maybe use window-tree

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

Richard M. Stallman wrote:

>    I think it copes with this. For the case of what I have called 
>    "interactive resize" (with the arrow keys) there are no problems. For 
>    the case of the new version of balance-windows (which I so far calls 
>    `bw-balance') I catch the errors and loop. So far I have seen no 
>    drawbacks with this.
>
>That is good.
>
>Could you please install your rewrite of balance-windows?
>That is a bug fix we want.  The other command is a new feature
>so it should not be installed now.
>
I have attached the patch. Could someone please install it?

[-- Attachment #2: windows-balance.patch --]
[-- Type: text/plain, Size: 10323 bytes --]

Index: window.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/window.el,v
retrieving revision 1.110
diff -c -r1.110 window.el
*** window.el	6 Dec 2005 09:00:49 -0000	1.110
--- window.el	7 Dec 2005 18:28:45 -0000
***************
*** 229,302 ****
  	  (= (nth 0 edges) (nth 0 (window-edges (next-window))))))))
  
  
! (defun balance-windows ()
!   "Make all visible windows the same height (approximately)."
    (interactive)
!   (let ((count -1) levels newsizes level-size
! 	;; Don't count the lines that are above the uppermost windows.
! 	;; (These are the menu bar lines, if any.)
! 	(mbl (nth 1 (window-edges (frame-first-window (selected-frame)))))
! 	(last-window (previous-window (frame-first-window (selected-frame))))
! 	;; Don't count the lines that are past the lowest main window.
! 	total)
!     ;; Bottom edge of last window determines what size we have to work with.
!     (setq total
! 	  (+ (window-height last-window)
! 	     (nth 1 (window-edges last-window))))
! 
!     ;; Find all the different vpos's at which windows start,
!     ;; then count them.  But ignore levels that differ by only 1.
!     (let (tops (prev-top -2))
!       (walk-windows (function (lambda (w)
! 				(setq tops (cons (nth 1 (window-edges w))
! 						 tops))))
! 		    'nomini)
!       (setq tops (sort tops '<))
!       (while tops
! 	(if (> (car tops) (1+ prev-top))
! 	    (setq prev-top (car tops)
! 		  count (1+ count)))
! 	(setq levels (cons (cons (car tops) count) levels))
! 	(setq tops (cdr tops)))
!       (setq count (1+ count)))
!     ;; Subdivide the frame into desired number of vertical levels.
!     (setq level-size (/ (- total mbl) count))
!     (save-selected-window
!       ;; Set up NEWSIZES to map windows to their desired sizes.
!       ;; If a window ends at the bottom level, don't include
!       ;; it in NEWSIZES.  Those windows get the right sizes
!       ;; by adjusting the ones above them.
!       (walk-windows (function
! 		     (lambda (w)
! 		       (let ((newtop (cdr (assq (nth 1 (window-edges w))
! 						levels)))
! 			     (newbot (cdr (assq (+ (window-height w)
! 						   (nth 1 (window-edges w)))
! 						levels))))
! 			 (if newbot
! 			     (setq newsizes
! 				   (cons (cons w (* level-size (- newbot newtop)))
! 					 newsizes))))))
! 		    'nomini)
!       ;; Make walk-windows start with the topmost window.
!       (select-window (previous-window (frame-first-window (selected-frame))))
!       (let (done (count 0))
! 	;; Give each window its precomputed size, or at least try.
! 	;; Keep trying until they all get the intended sizes,
! 	;; but not more than 3 times (to prevent infinite loop).
! 	(while (and (not done) (< count 3))
! 	  (setq done t)
! 	  (setq count (1+ count))
! 	  (walk-windows (function (lambda (w)
! 				    (select-window w)
! 				    (let ((newsize (cdr (assq w newsizes))))
! 				      (when newsize
! 					(enlarge-window (- newsize
! 							   (window-height))
! 							nil)
! 					(unless (= (window-height) newsize)
! 					  (setq done nil))))))
! 			'nomini))))))
  \f
  ;; I think this should be the default; I think people will prefer it--rms.
  (defcustom split-window-keep-point t
--- 229,442 ----
  	  (= (nth 0 edges) (nth 0 (window-edges (next-window))))))))
  
  
! \f
! ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
! ;;; New code for `balance-windows' using `window-tree'
! 
! ;;; Translate from internal window tree format
! 
! (defun bw-get-tree (&optional window-or-frame)
!   "Get a window split tree in our format.
! 
! WINDOW-OR-FRAME must be nil, a frame or a window.  If it is nil
! then the whole window split tree for `selected-frame' is
! returned.  If it is a frame then this is used instead.  If it is
! a window then the smallest tree containing that window is
! returned."
!   (when window-or-frame
!     (unless (or (framep window-or-frame)
!                 (windowp window-or-frame))
!       (error "Not a frame or window: %s" frame)))
!   (let ((subtree (bw-find-tree-sub window-or-frame)))
!     (if (integerp subtree)
!         nil
!       (bw-get-tree-1 subtree))))
! 
! (defun bw-get-tree-1 (split)
!   (if (windowp split)
!       split
!     (let ((dir (car split))
!           (edges (car (cdr split)))
!           (childs (cdr (cdr split))))
!       (list
!        (cons 'dir (if dir 'ver 'hor))
!        (cons 'b (nth 3 edges))
!        (cons 'r (nth 2 edges))
!        (cons 't (nth 1 edges))
!        (cons 'l (nth 0 edges))
!        (cons 'childs (mapcar #'bw-get-tree-1 childs))))))
! 
! (defun bw-find-tree-sub (window-or-frame &optional get-parent)
!   (let* ((window (when (windowp window-or-frame) window-or-frame))
!          (frame (when (windowp window) (window-frame window)))
!          (wt (car (window-tree frame))))
!     (when (< 1 (length (window-list frame 0)))
!       (if window
!           (bw-find-tree-sub-1 wt window get-parent)
!         wt))))
! 
! (defun bw-find-tree-sub-1 (tree win &optional get-parent)
!   (unless (windowp win) (error "Not a window: %s" win))
!   (if (memq win tree)
!       (if get-parent
!           get-parent
!         tree)
!     (let ((childs (cdr (cdr tree)))
!           child
!           subtree)
!       (while (and childs (not subtree))
!         (setq child (car childs))
!         (setq childs (cdr childs))
!         (when (and child (listp child))
!           (setq subtree (bw-find-tree-sub-1 child win get-parent))))
!       (if (integerp subtree)
!           (progn
!             (if (= 1 subtree)
!                 tree
!               (1- subtree)))
!         subtree
!         ))))
! 
! 
! 
! ;;; Window or object edges
! 
! (defun bw-l(obj)
!   "Left edge of OBJ."
!   (if (windowp obj) (nth 0 (window-edges obj)) (cdr (assq 'l obj))))
! (defun bw-t(obj)
!   "Top edge of OBJ."
!   (if (windowp obj) (nth 1 (window-edges obj)) (cdr (assq 't obj))))
! (defun bw-r(obj)
!   "Right edge of OBJ."
!   (if (windowp obj) (nth 2 (window-edges obj)) (cdr (assq 'r obj))))
! (defun bw-b(obj)
!   "Bottom edge of OBJ."
!   (if (windowp obj) (nth 3 (window-edges obj)) (cdr (assq 'b obj))))
! 
! 
! 
! 
! 
! ;;; Split directions
! 
! (defun bw-dir(obj)
!   "Return window split tree direction if OBJ.
! If OBJ is a window return 'both. If it is a window split tree
! then return its direction."
!   (if (symbolp obj)
!       obj
!     (if (windowp obj)
!         'both
!       (let ((dir (cdr (assq 'dir obj))))
!         (unless (memq dir '(hor ver both))
!           (error "Can't find dir in %s" obj))
!         dir))))
! 
! (defun bw-eqdir(obj1 obj2)
!   "Return t if window split tree directions are equal.
! OBJ1 and OBJ2 should be either windows or window split trees in
! our format. The directions returned by `bw-dir' are compared and
! t is returned if they are `eq' or one of them is 'both."
!   (let ((dir1 (bw-dir obj1))
!         (dir2 (bw-dir obj2)))
!     (or (eq dir1 dir2)
!         (eq dir1 'both)
!         (eq dir2 'both))))
! 
! 
! 
! ;;; Building split tree
! 
! (defun bw-refresh-edges(obj)
!   "Refresh the edge information of OBJ and return OBJ."
!   (unless (windowp obj)
!     (let ((childs (cdr (assq 'childs obj)))
!           (ol 1000)
!           (ot 1000)
!           (or -1)
!           (ob -1))
!       (dolist (o childs)
!         (when (> ol (bw-l o)) (setq ol (bw-l o)))
!         (when (> ot (bw-t o)) (setq ot (bw-t o)))
!         (when (< or (bw-r o)) (setq or (bw-r o)))
!         (when (< ob (bw-b o)) (setq ob (bw-b o))))
!       (setq obj (delq 'l obj))
!       (setq obj (delq 't obj))
!       (setq obj (delq 'r obj))
!       (setq obj (delq 'b obj))
!       (add-to-list 'obj (cons 'l ol))
!       (add-to-list 'obj (cons 't ot))
!       (add-to-list 'obj (cons 'r or))
!       (add-to-list 'obj (cons 'b ob))
!       ))
!   obj)
! 
! 
! 
! 
! ;;; Balance windows
! 
! (defun balance-windows(&optional window-or-frame)
!   "Make windows the same heights or widths in window split subtrees.
! 
! When called non-interactively WINDOW-OR-FRAME may be either a
! window or a frame. It then balances the windows on the implied
! frame. If the parameter is a window only the corresponding window
! subtree is balanced."
    (interactive)
!   (let (
!         (wt (bw-get-tree window-or-frame))
!         (w)
!         (h)
!         (tried-sizes)
!         (last-sizes)
!         (windows (window-list nil 0))
!         (counter 0))
!     (when wt
!       (while (not (member last-sizes tried-sizes))
!         (when last-sizes (setq tried-sizes (cons last-sizes tried-sizes)))
!         (setq last-sizes (mapcar (lambda(w)
!                                    (window-edges w))
!                                  windows))
!         (when (eq 'hor (bw-dir wt))
!           (setq w (- (bw-r wt) (bw-l wt))))
!         (when (eq 'ver (bw-dir wt))
!           (setq h (- (bw-b wt) (bw-t wt))))
!         (bw-balance-sub wt w h)))))
! 
! (defun bw-adjust-window(window delta horizontal)
!   "Wrapper around `adjust-window-trailing-edge' with error checking.
! Arguments WINDOW, DELTA and HORIZONTAL are passed on to that function."
!   (condition-case err
!       (adjust-window-trailing-edge window delta horizontal)
!     (error
!      ;;(message "adjust: %s" (error-message-string err))
!      )))
! 
! (defun bw-balance-sub(wt w h)
!   (setq wt (bw-refresh-edges wt))
!   (unless w (setq w (- (bw-r wt) (bw-l wt))))
!   (unless h (setq h (- (bw-b wt) (bw-t wt))))
!   (if (windowp wt)
!       (progn
!         (when w
!           (let ((dw (- w (- (bw-r wt) (bw-l wt)))))
!             (when (/= 0 dw)
!                 (bw-adjust-window wt dw t))))
!         (when h
!           (let ((dh (- h (- (bw-b wt) (bw-t wt)))))
!             (when (/= 0 dh)
!               (bw-adjust-window wt dh nil)))))
!     (let* ((childs (cdr (assq 'childs wt)))
!            (lastchild (car (last childs)))
!            (cw (when w (/ w (if (bw-eqdir 'hor wt) (length childs) 1))))
!            (ch (when h (/ h (if (bw-eqdir 'ver wt) (length childs) 1)))))
!       (dolist (c childs)
!           (bw-balance-sub c cw ch)))))
! 
! ;;; End of new code for `balance-windows'
! ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  \f
  ;; I think this should be the default; I think people will prefer it--rms.
  (defcustom split-window-keep-point t

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel