Bug in window resizing?

Bug in window resizing?

[Lennart Borgman]

While trying to finish a new version of balance-windows I discovered 
what seems to be a bug: When I try to resize a window by dragging the 
lower border the upper border of this window is instead moved.

This looks very weird and unexpected so I would be glad for confirmation 
of the behaviour by others. Do the following:

  emacs -Q
  C-x 2, C-x 3, C-x 2

You should then arrive at a window geometry something like this (view 
with fixed char width):

+-------------+-----------+
|             |           |
+-moves down--+           +
|             |           |
+---drag up---+-----------+
|                         |
|                         |
|                         |
+-------------------------+

The strange thing is that when I try to drag the border marked with 
"drag up" this border does not move, but the border above moves down. 
(It seems like this does not only happen while dragging, but this is the 
most easy way to demonstrate it.)

This happens to me on w32 with CVS Emacs built 2005-09-03. I have 
applied some patches to the C sources, but none that I would believe 
could influence this.

Re: Bug in window resizing?

[Richard M. Stallman]

I will eventually work on this if nobody else does first.
But I hope someone else will debug it, so I don't have to.

Re: Bug in window resizing?

[Lennart Borgman]

Richard M. Stallman wrote:

>I will eventually work on this if nobody else does first.
>But I hope someone else will debug it, so I don't have to.
>  
>
I do not know if this helps, but the flaw is in the logic, not in any 
details. Consider the case I looked at, ie the windows after C-x 2, C-x 
3, C-x 2. The selected window now has a bottom border that is divided 
horizontally. I think this is not taken into account in enlarge_window, 
which at a quick glance just seems to consider the selected window's 
siblings.

What is needed (I believe) is to go up one level in the split tree, find 
the window under the selected window and then resize this. Or maybe it 
is even more complicated than that?

I do not think however that I am the right person to try to fix this now.

Re: Bug in window resizing?

[Richard M. Stallman]

    What is needed (I believe) is to go up one level in the split tree, find 
    the window under the selected window and then resize this. Or maybe it 
    is even more complicated than that?

Yes, I think you are right.  It seems that the only feasible way to
fix this is to make a new interface.  Since that change is already
being discussed, I think we should simply go ahead with that.

Is anyone working on that?

Re: Bug in window resizing?

[Lennart Borgman]

Richard M. Stallman wrote:

>    What is needed (I believe) is to go up one level in the split tree, find 
>    the window under the selected window and then resize this. Or maybe it 
>    is even more complicated than that?
>
>Yes, I think you are right.  It seems that the only feasible way to
>fix this is to make a new interface.  Since that change is already
>being discussed, I think we should simply go ahead with that.
>
>Is anyone working on that?
>  
>
I think this bug is still there. You can see this bug if you first split 
windows with C-x 2, C-x 3, C-x 2. Now try to move the bottom of the 
second window to the left.

Kim, did you look at this when you made `window-tree'? Or perhaps could 
you look at it now? I do not think I understand the subtle details here ;-)

Re: Bug in window resizing?

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Richard M. Stallman wrote:
>
>>    What is needed (I believe) is to go up one level in the split
>> tree, find    the window under the selected window and then resize
>> this. Or maybe it    is even more complicated than that?
>>
>>Yes, I think you are right.  It seems that the only feasible way to
>>fix this is to make a new interface.  Since that change is already
>>being discussed, I think we should simply go ahead with that.
>>
>>Is anyone working on that?
>>  
>>
> I think this bug is still there. You can see this bug if you first
> split windows with C-x 2, C-x 3, C-x 2. Now try to move the bottom of
> the second window to the left.
>
> Kim, did you look at this when you made `window-tree'? Or perhaps
> could you look at it now? I do not think I understand the subtle
> details here ;-)

I implemented window-tree for the purpose of balance-windows.
I didn't correlate it to this problem.

AFAICS, enlarge-window works just fine in that window (try C-x ^), so
if the code in mouse-drag-mode-line-1 would just selected the proper
window, it should work (without finding the parent window).

Could you try to find out why the wrong window is selected?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug in window resizing?

[Lennart Borgman]

Kim F. Storm wrote:

>Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>  
>
>>Richard M. Stallman wrote:
>>
>>    
>>
>>>   What is needed (I believe) is to go up one level in the split
>>>tree, find    the window under the selected window and then resize
>>>this. Or maybe it    is even more complicated than that?
>>>
>>>Yes, I think you are right.  It seems that the only feasible way to
>>>fix this is to make a new interface.  Since that change is already
>>>being discussed, I think we should simply go ahead with that.
>>>
>>>Is anyone working on that?
>>> 
>>>
>>>      
>>>
>>I think this bug is still there. You can see this bug if you first
>>split windows with C-x 2, C-x 3, C-x 2. Now try to move the bottom of
>>the second window to the left.
>>
>>Kim, did you look at this when you made `window-tree'? Or perhaps
>>could you look at it now? I do not think I understand the subtle
>>details here ;-)
>>    
>>
>
>I implemented window-tree for the purpose of balance-windows.
>I didn't correlate it to this problem.
>
>AFAICS, enlarge-window works just fine in that window (try C-x ^), so
>if the code in mouse-drag-mode-line-1 would just selected the proper
>window, it should work (without finding the parent window).
>  
>
No, it does not work if you use (enlarge-window 1 nil t) in that window. 
I did look at the C code before, see the sentence beginning with "What 
is needed ... " above. I just think it is best I do not touch this part 
of the C code.

Re: Bug in window resizing?

[Richard M. Stallman]

    Kim, did you look at this when you made `window-tree'? Or perhaps could 
    you look at it now? I do not think I understand the subtle details here ;-)

window-tree just reports on the structure of windows; it does not
alter anything about how window resizing works.  So if there was a
bug, window-tree might be useful in fixing it, but someone still has
to fix it.

Re: Bug in window resizing?

[Lennart Borgman]

Lennart Borgman wrote:

> Kim F. Storm wrote:
>
>>>>     
>>>
>>> I think this bug is still there. You can see this bug if you first
>>> split windows with C-x 2, C-x 3, C-x 2. Now try to move the bottom of
>>> the second window to the left.
>>>
>>> Kim, did you look at this when you made `window-tree'? Or perhaps
>>> could you look at it now? I do not think I understand the subtle
>>> details here ;-)
>>
To Kim:

I got your message about this and I will look into it a bit since you 
did not have time. I am however unable to mail you privately for some 
reason. Some spam filter seems to reject the messages.

Re: Bug in window resizing?

[Lennart Borgman]

Lennart Borgman wrote:

> Kim F. Storm wrote:
>
>> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>>
>>  
>>
>>> Richard M. Stallman wrote:
>>>
>>>   
>>>
>>>>   What is needed (I believe) is to go up one level in the split
>>>> tree, find    the window under the selected window and then resize
>>>> this. Or maybe it    is even more complicated than that?
>>>>
>>>> Yes, I think you are right.  It seems that the only feasible way to
>>>> fix this is to make a new interface.  Since that change is already
>>>> being discussed, I think we should simply go ahead with that.
>>>>
>>>> Is anyone working on that?
>>>>
>>>>
>>>>     
>>>
>>> I think this bug is still there. You can see this bug if you first
>>> split windows with C-x 2, C-x 3, C-x 2. Now try to move the bottom of
>>> the second window to the left.
>>>
>>> Kim, did you look at this when you made `window-tree'? Or perhaps
>>> could you look at it now? I do not think I understand the subtle
>>> details here ;-)
>>>   
>>
>>
>> I implemented window-tree for the purpose of balance-windows.
>> I didn't correlate it to this problem.
>>
>> AFAICS, enlarge-window works just fine in that window (try C-x ^), so
>> if the code in mouse-drag-mode-line-1 would just selected the proper
>> window, it should work (without finding the parent window).
>>  
>>
> No, it does not work if you use (enlarge-window 1 nil t) in that 
> window. I did look at the C code before, see the sentence beginning 
> with "What is needed ... " above. I just think it is best I do not 
> touch this part of the C code.

I have decided I can unfortunately not fix this bug now. A quite 
complicated rewrite of `enlarge-window' is needed.

I run into this when I tried to finish the rewrite of `balance-windows'. 
I have written a new version of balance-windows and it works (I 
belieive) but since Kim's patch gave some new possibilities I wanted to 
enhance it a bit. The rewrite contains three functions:

1) A rewrite of balance-windows (at the moment called bw-balance, C-x + +)
2) A new function to balance only the siblings in the tree from 
`window-tree' (bw-balance-siblings, C-x + .)
3) A temporary mode for resizing current window with the arrow keys 
(started with C-x +)

The bug in enlarge-window is more visible now because of 3 above. 
However if you try to resize using the mouse you see the same problem.

Please test the new functions. They are in 
http://ourcomments.org/Emacs/DL/elisp/test/bwcvs.el

Re: Bug in window resizing?

[Richard M. Stallman]

    I run into this when I tried to finish the rewrite of `balance-windows'. 
    I have written a new version of balance-windows and it works (I 
    belieive) but since Kim's patch gave some new possibilities I wanted to 
    enhance it a bit. The rewrite contains three functions:

    1) A rewrite of balance-windows (at the moment called bw-balance, C-x + +)
    2) A new function to balance only the siblings in the tree from 
    `window-tree' (bw-balance-siblings, C-x + .)
    3) A temporary mode for resizing current window with the arrow keys 
    (started with C-x +)

Can you make use of the new function adjust-window-trailing-edge
to make these work right?

It might be hard to use that function, since it won't allow moving an
edge too close to another edge.  To change move several edges could be
like a sliding blocks puzzle.  We might need another new function that
takes a modified window-tree and installs all the new edges.