[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RP] Re: bugs?
From: |
shawn |
Subject: |
Re: [RP] Re: bugs? |
Date: |
Tue Oct 9 23:31:09 2001 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.105 |
Mike Meyer <address@hidden> writes:
> > > On Sun, Oct 07, 2001 at 01:30:43PM -0500, Mike Meyer wrote:
> > > > Yes, the rp command remove, to remove the frame, and not delete to
> > > > delete the window.
> > >
> > > The logical thing would, of course, be that Frame A & B were given that
> > > space in that case.
> >
> > This is what happens on my box. I don't use frames very often, but
> > I've never seen this happen. If you could find a way to reliably
> > create the bug, it would help a lot in finding out where its going
> > wrong.
>
> Ok, try this sequence...
>
> bind T exec ratpoison -c vsplit -c vsplit -c vsplit -c focusright -c
> focusright -c vsplit -c focusright -c vsplit -c focusright -c focusright -c
> hsplit -c focusdown -c remove
>
> That reliably leaves the lower right-hand corner out of the frame list.
Ok, its fixed in CVS.
+----+-----+
| | B |
| A | |
| +-----+
| | C |
+----------+
The problem simplified to deleting C from the above
configuration. Window A would grow vertically and take up the right
amount of space and rp figured it was a match. If this happens before
frame B is checked, it messes up. I added a test to make sure the
window taking up the deleted frame's space actually overlaps the
delete window (in this case C).