* [rudalics@gmx.at: enlarge-window with preserve-before non-nil] @ 2005-05-04 16:25 Richard Stallman 2005-05-08 20:24 ` Jan D. 0 siblings, 1 reply; 10+ messages in thread From: Richard Stallman @ 2005-05-04 16:25 UTC (permalink / raw) 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 ------- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil] 2005-05-04 16:25 [rudalics@gmx.at: enlarge-window with preserve-before non-nil] Richard Stallman @ 2005-05-08 20:24 ` Jan D. 2005-05-09 21:03 ` Richard Stallman 0 siblings, 1 reply; 10+ messages in thread From: Jan D. @ 2005-05-08 20:24 UTC (permalink / raw) Cc: emacs-devel 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 > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil] 2005-05-08 20:24 ` Jan D. @ 2005-05-09 21:03 ` Richard Stallman 2005-05-14 18:48 ` Jan D. 0 siblings, 1 reply; 10+ messages in thread From: Richard Stallman @ 2005-05-09 21:03 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil] 2005-05-09 21:03 ` Richard Stallman @ 2005-05-14 18:48 ` Jan D. 2005-05-15 15:59 ` Richard Stallman 0 siblings, 1 reply; 10+ messages in thread From: Jan D. @ 2005-05-14 18:48 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil] 2005-05-14 18:48 ` Jan D. @ 2005-05-15 15:59 ` Richard Stallman 2005-05-17 4:47 ` Jan D. ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Richard Stallman @ 2005-05-15 15:59 UTC (permalink / raw) Cc: emacs-devel | 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.) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil] 2005-05-15 15:59 ` Richard Stallman @ 2005-05-17 4:47 ` Jan D. 2005-05-17 11:58 ` Stefan Monnier 2005-06-06 10:43 ` Jan D. 2 siblings, 0 replies; 10+ messages in thread From: Jan D. @ 2005-05-17 4:47 UTC (permalink / raw) Cc: emacs-devel > > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil] 2005-05-15 15:59 ` Richard Stallman 2005-05-17 4:47 ` Jan D. @ 2005-05-17 11:58 ` Stefan Monnier 2005-06-06 10:43 ` Jan D. 2 siblings, 0 replies; 10+ messages in thread From: Stefan Monnier @ 2005-05-17 11:58 UTC (permalink / raw) Cc: Jan D., emacs-devel > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil] 2005-05-15 15:59 ` Richard Stallman 2005-05-17 4:47 ` Jan D. 2005-05-17 11:58 ` Stefan Monnier @ 2005-06-06 10:43 ` Jan D. 2005-06-06 16:37 ` Richard Stallman 2005-06-27 8:35 ` martin rudalics 2 siblings, 2 replies; 10+ messages in thread From: Jan D. @ 2005-06-06 10:43 UTC (permalink / raw) Cc: rudalics, rms 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil] 2005-06-06 10:43 ` Jan D. @ 2005-06-06 16:37 ` Richard Stallman 2005-06-27 8:35 ` martin rudalics 1 sibling, 0 replies; 10+ messages in thread From: Richard Stallman @ 2005-06-06 16:37 UTC (permalink / raw) Cc: rudalics, emacs-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rudalics@gmx.at: enlarge-window with preserve-before non-nil] 2005-06-06 10:43 ` Jan D. 2005-06-06 16:37 ` Richard Stallman @ 2005-06-27 8:35 ` martin rudalics 1 sibling, 0 replies; 10+ messages in thread From: martin rudalics @ 2005-06-27 8:35 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-06-27 8:35 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-05-04 16:25 [rudalics@gmx.at: enlarge-window with preserve-before non-nil] Richard Stallman 2005-05-08 20:24 ` Jan D. 2005-05-09 21:03 ` Richard Stallman 2005-05-14 18:48 ` Jan D. 2005-05-15 15:59 ` Richard Stallman 2005-05-17 4:47 ` Jan D. 2005-05-17 11:58 ` Stefan Monnier 2005-06-06 10:43 ` Jan D. 2005-06-06 16:37 ` Richard Stallman 2005-06-27 8:35 ` martin rudalics
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.