[rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[Richard Stallman]

Can someone please investigate this, and ack?

------- Start of forwarded message -------
X-Authenticated: #14592706
Date: Sun, 01 May 2005 14:21:26 +0200
From: martin rudalics <rudalics@gmx.at>
X-Accept-Language: de-DE, de, en-us, en
To: emacs-pretest-bug <emacs-pretest-bug@gnu.org>
X-Y-GMX-Trusted: 0
Subject: enlarge-window with preserve-before non-nil
Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63

Suppose I start with a single window called W1 (window names are
fictional)

W1

split W1 horizontally

W1 | W2

split W2 vertically

    | W2
W1 |---
    | W3

delete W1

W2
- --
W3

split W2 horizontally

W2 | W4
- -------
    W3

split W4 vertically

    | W4
W2 |---
    | W5
- -------
    W3

and delete W2

W4
- --
W5
- --
W3

At this moment I can't enlarge W5 any more by "dragging its modeline
down" - the window configuration appears "frozen".  The attempt to
shrink W5 by dragging its modeline "up" has an effect similar to that of
dragging W4's modeline down, that means, W4 gets enlarged and not W3.
Likely, in this scenario siblings got confused before issuing the call
to `enlarge-window' with PRESERVE-BEFORE non-nil.



_______________________________________________
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[Jan D.]

Richard Stallman wrote:

>Can someone please investigate this, and ack?
>  
>

I looked a bit, but I am not sure how it shall work.  If I just to three 
windows, in the obvious way (C-x 2, C-x 2), I get three windows, one 11 
lines, one 12 lines and one 24 lines.  This gives me this window 
configuration:

0x86b6b10: vchild: 0x861d830, hchild: 0x0, next: 0x861d9c8, parent: 0x0, 
h: 47
0x861d830: vchild: 0x0, hchild: 0x0, next: 0x8694a50, parent: 0x86b6b10, 
h: 11
0x8694a50: vchild: 0x0, hchild: 0x0, next: 0x86b6ca8, parent: 0x86b6b10, 
h: 12
0x86b6ca8: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x86b6b10, h: 24
0x861d9c8: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x0, h: 1

But if I create the same three windows (11, 12 and 24 lines) with the 
method below, I get this window configuration:

0x8833558: vchild: 0x87f9978, hchild: 0x0, next: 0x861d9c8, parent: 0x0, 
h: 47
0x87f9978: vchild: 0x86a7a48, hchild: 0x0, next: 0x8820a48, parent: 
0x8833558, h: 23
0x86a7a48: vchild: 0x0, hchild: 0x0, next: 0x87b6d68, parent: 0x87f9978, 
h: 11
0x87b6d68: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x87f9978, h: 12
0x8820a48: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x8833558, h: 24
0x861d9c8: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x0, h: 1

When enlarge-window shall enlarge a window (the one with 12 lines in 
this case), it calculates the maximum lines it can enlarge it to.  Since 
enlarge-window gets called with PRESERVE_BEFORE set to t, in the first 
case this is:
 47 (the parent) - 11 (the sibling to preserve) = 36 (> 12, i.e. enlarge 
is OK).

In the second case:
 23 (the parent) - 11 (the sibling to preserve) = 12 (i.e. can not enlarge).


If the window trees shall be the same, there is a bug in adding/removing 
windows, as the extra 23 line parent then should be removed.  But it may 
be a bug in enlarge-window also, it should in the second case use the 
topmost parents height.

    Jan D.

>------- Start of forwarded message -------
>X-Authenticated: #14592706
>Date: Sun, 01 May 2005 14:21:26 +0200
>From: martin rudalics <rudalics@gmx.at>
>X-Accept-Language: de-DE, de, en-us, en
>To: emacs-pretest-bug <emacs-pretest-bug@gnu.org>
>X-Y-GMX-Trusted: 0
>Subject: enlarge-window with preserve-before non-nil
>Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
>X-Spam-Level: 
>X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
>
>Suppose I start with a single window called W1 (window names are
>fictional)
>
>W1
>
>split W1 horizontally
>
>W1 | W2
>
>split W2 vertically
>
>    | W2
>W1 |---
>    | W3
>
>delete W1
>
>W2
>- --
>W3
>
>split W2 horizontally
>
>W2 | W4
>- -------
>    W3
>
>split W4 vertically
>
>    | W4
>W2 |---
>    | W5
>- -------
>    W3
>
>and delete W2
>
>W4
>- --
>W5
>- --
>W3
>
>At this moment I can't enlarge W5 any more by "dragging its modeline
>down" - the window configuration appears "frozen".  The attempt to
>shrink W5 by dragging its modeline "up" has an effect similar to that of
>dragging W4's modeline down, that means, W4 gets enlarged and not W3.
>Likely, in this scenario siblings got confused before issuing the call
>to `enlarge-window' with PRESERVE-BEFORE non-nil.
>
>
>
>_______________________________________________
>Emacs-pretest-bug mailing list
>Emacs-pretest-bug@gnu.org
>http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
>------- End of forwarded message -------
>
>
>_______________________________________________
>Emacs-devel mailing list
>Emacs-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/emacs-devel
>  
>

Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[Richard Stallman]

    I looked a bit, but I am not sure how it shall work.  If I just to three 
    windows, in the obvious way (C-x 2, C-x 2), I get three windows, one 11 
    lines, one 12 lines and one 24 lines.  This gives me this window 
    configuration:

    0x86b6b10: vchild: 0x861d830, hchild: 0x0, next: 0x861d9c8, parent: 0x0, 
    h: 47
    0x861d830: vchild: 0x0, hchild: 0x0, next: 0x8694a50, parent: 0x86b6b10, 
    h: 11
    0x8694a50: vchild: 0x0, hchild: 0x0, next: 0x86b6ca8, parent: 0x86b6b10, 
    h: 12
    0x86b6ca8: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x86b6b10, h: 24
    0x861d9c8: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x0, h: 1

That's the correct configuration for such a case.


    But if I create the same three windows (11, 12 and 24 lines) with the 
    method below, I get this window configuration:

    0x8833558: vchild: 0x87f9978, hchild: 0x0, next: 0x861d9c8, parent: 0x0, 
    h: 47
    0x87f9978: vchild: 0x86a7a48, hchild: 0x0, next: 0x8820a48, parent: 
    0x8833558, h: 23
    0x86a7a48: vchild: 0x0, hchild: 0x0, next: 0x87b6d68, parent: 0x87f9978, 
    h: 11
    0x87b6d68: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x87f9978, h: 12
    0x8820a48: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x8833558, h: 24
    0x861d9c8: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x0, h: 1

This is a bug.  A window which is a vchild should never have a vchild.

Can you determine at which step the structure first becomes
incorrect?  That is where the bug is, I think.

Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[Jan D.]

Richard Stallman wrote:

>    I looked a bit, but I am not sure how it shall work.  If I just to three 
>    windows, in the obvious way (C-x 2, C-x 2), I get three windows, one 11 
>    lines, one 12 lines and one 24 lines.  This gives me this window 
>    configuration:
>
>    0x86b6b10: vchild: 0x861d830, hchild: 0x0, next: 0x861d9c8, parent: 0x0, 
>    h: 47
>    0x861d830: vchild: 0x0, hchild: 0x0, next: 0x8694a50, parent: 0x86b6b10, 
>    h: 11
>    0x8694a50: vchild: 0x0, hchild: 0x0, next: 0x86b6ca8, parent: 0x86b6b10, 
>    h: 12
>    0x86b6ca8: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x86b6b10, h: 24
>    0x861d9c8: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x0, h: 1
>
>That's the correct configuration for such a case.
>
>
>    But if I create the same three windows (11, 12 and 24 lines) with the 
>    method below, I get this window configuration:
>
>    0x8833558: vchild: 0x87f9978, hchild: 0x0, next: 0x861d9c8, parent: 0x0, 
>    h: 47
>    0x87f9978: vchild: 0x86a7a48, hchild: 0x0, next: 0x8820a48, parent: 
>    0x8833558, h: 23
>    0x86a7a48: vchild: 0x0, hchild: 0x0, next: 0x87b6d68, parent: 0x87f9978, 
>    h: 11
>    0x87b6d68: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x87f9978, h: 12
>    0x8820a48: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x8833558, h: 24
>    0x861d9c8: vchild: 0x0, hchild: 0x0, next: 0x0, parent: 0x0, h: 1
>
>This is a bug.  A window which is a vchild should never have a vchild.
>
>Can you determine at which step the structure first becomes
>incorrect?  That is where the bug is, I think.
>

I think it is correct up to the last delete, but correct me if I'm 
wrong.  Steps in the chain are  represented like this (arrow down = 
next, arrow diagonal = vchild, arrow horizontal = hchild, parent in 
parentesis):

w1 | w2

 i0 -----> w1 (i0)
  |             |
  v             v
minibuf    w2 (i0)



    | W2
W1  |---
    | W3

 i0 ----> w1 (i0)
  |        |
minibuf   i1 (i0)
            \
             w2 (i1)
             |
             w3 (u1) 



 w2
-----
 w3

 i1
  |\
  | \
  |  \
  |   w2 (i1)
  |     |
minibuf w3 (i1)



W2 | W4
--------
   W3

 i1
  |\
  | i2 (i1) --> w2 (i2)
  |   |          |
  |  w3 (i1)    w4 (i2)
  | 
minibuf
  


    | W4
W2  |---
    | W5
- -------
    W3


  i1
  | \
  |  i2 (i1) --> w2 (i2)
  |   |            |
  |  w3 (i1)     i3 (i2)
  |                 \
  |                 w4 (i3)
  |                   |
 minibuf            w5 (i3)




  w4
------
  w5
------
  w3

  i1
  | \
  |  \
  |   i3 (i1)
  |    |    \
  | w3 (i1)  \
  |          w4 (i3)
  |           |
minibuf      w5 (i3)


I think it is correct up to the last delete of w2.  But what the rule should be for eliminating i3 in the last step I don't know.  I think this is the desired last step:

  i1
  | \
  |  \
  |  w4 (i1)
  |     |
  |  w5 (i1)
  |     |
  |  w3 (i1)
  |
minibuf

i1 possibly replaced with i3.



	Jan D.

Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[Richard Stallman]

	| W4
    W2  |---
	| W5
    - -------
	W3


      i1
      | \
      |  i2 (i1) --> w2 (i2)
      |   |            |
      |  w3 (i1)     i3 (i2)
      |                 \
      |                 w4 (i3)
      |                   |
     minibuf            w5 (i3)



That structure is correct.


      w4
    ------
      w5
    ------
      w3

      i1
      | \
      |  \
      |   i3 (i1)
      |    |    \
      | w3 (i1)  \
      |          w4 (i3)
      |           |
    minibuf      w5 (i3)

That structure is erroneous.
i3 should not exist.

    I think it is correct up to the last delete of w2.  But what the
    rule should be for eliminating i3 in the last step I don't know.
    I think this is the desired last step:

      i1
      | \
      |  \
      |  w4 (i1)
      |     |
      |  w5 (i1)
      |     |
      |  w3 (i1)
      |
    minibuf

    i1 possibly replaced with i3.

The incorrect structure is in i3, so I think it should eliminate i3.
The criterion for doing so is that i3 is a vchild of its parent
and also has a vchild.  That should never occur.

After the code operates on i3, putting it in place of i2, it check if
i3 is a vchild and has a vchild.  If so, it should to eliminate i3,
putting w4 into its place in the structure, and make w3 be the next of
w5.

Want to implement that?

(The same thing should be done with hchild.)

Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[Jan D.]

>
> The incorrect structure is in i3, so I think it should eliminate i3.
> The criterion for doing so is that i3 is a vchild of its parent
> and also has a vchild.  That should never occur.
>
> After the code operates on i3, putting it in place of i2, it check if
> i3 is a vchild and has a vchild.  If so, it should to eliminate i3,
> putting w4 into its place in the structure, and make w3 be the next of
> w5.
>
> Want to implement that?
>
> (The same thing should be done with hchild.)
>

I can implement that.

     Jan D.

Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[Stefan Monnier]

> The criterion for doing so is that i3 is a vchild of its parent
> and also has a vchild.  That should never occur.

Whoever can do that, please sprinkle some corresponding asserts in the code.


        Stefan

Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[Jan D.]

Richard Stallman wrote:

>The incorrect structure is in i3, so I think it should eliminate i3.
>The criterion for doing so is that i3 is a vchild of its parent
>and also has a vchild.  That should never occur.
>
>After the code operates on i3, putting it in place of i2, it check if
>i3 is a vchild and has a vchild.  If so, it should to eliminate i3,
>putting w4 into its place in the structure, and make w3 be the next of
>w5.
>
>Want to implement that?
>
>(The same thing should be done with hchild.)
>
>  
>

Stefan Monnier wrote:

>Whoever can do that, please sprinkle some corresponding asserts in the code.
>  
>

I finally checked in a fix for this, but I didn't feel I could add any 
asserts that I was sure about, sorry.

    Jan D.

Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[Richard Stallman]

    I finally checked in a fix for this, but I didn't feel I could add any 
    asserts that I was sure about, sorry.

Thanks for fixing it.

Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil]

[martin rudalics]

> I finally checked in a fix for this, but I didn't feel I could add any 
> asserts that I was sure about, sorry.
> 
>    Jan D.
> 
> 

Works fine.  Thanks a lot for resolving this problem.  martin