1:27 a.m.
Michael Sperber writes in a commit notice on XEmacs Patches:
Hg log:
Fix window-configuration problem.
This greatly improves, maybe eliminates, the anomolies I've been
seeing in VM summary buffers with random point movement. This is an
X-enabled build but in a TTY over ssh. Can other VM testers update to
tip of "xemacs" (or if you're following "xemacs-beta", it should
be
there in a day or two -- my build was clean FWIW) and report if you
see an improvement, or continuing anomolies?
In a quick test, it does *not* fix issue303 for me (but I have not
done a full rebuild with the patch yet, just a "make").
Mike, Jerry, the following issues in the tracker may be related.
issue134, Infinite loop in ecb, apparently in current-window-configuration
issue227, Infinite loop in ecb, apparently in current-window-configuration
issue303, [Bug: 21.5-b28] Bogus motion of modeline
I've assigned them to Mike but 134 and 227 might better be assigned to
Jerry and/or closed if they've been fixed. If 134 and 227 are the
same issue, please close one as superseded by the other. I think 227
has more information, so 134 is the better candidate for that.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:53 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
In a quick test, it does *not* fix issue303 for me (but I have not
done a full rebuild with the patch yet, just a "make").
[...]
issue303, [Bug: 21.5-b28] Bogus motion of modeline
I don't see it: For me, the echo area goes to 2 lines and stays there.
The middle modeline creeps up by one but stays there. If nobody
confirms the problem's still there, I intend to close this one.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:32 a.m.
Michael Sperber writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> In a quick test, it does *not* fix issue303 for me (but I have not
> done a full rebuild with the patch yet, just a "make").
> [...]
> issue303, [Bug: 21.5-b28] Bogus motion of modeline
I don't see it: For me, the echo area goes to 2 lines and stays there.
If you don't get the echo area to return to one line height, you're
not executing the recipe correctly, or perhaps you've customized
`resize-minibuffer-window-exactly' to nil.
The middle modeline creeps up by one but stays there. If nobody
confirms the problem's still there, I intend to close this one.
First, why is *any* permanent motion OK? If you want to push priority
down to zero or unassign yourself from the bug, that's one thing, but
but this is not backward compatible (assuming default settings), and
there's no specification that says this is desirable behavior or what
to expect in slightly different situations.
FWIW, I'm getting desired behavior in this XEmacs, `XEmacs 21.5
(beta28) "fuki" 2785829fe37c [Lucid] (x86_64-unknown-linux, Mule) of
Thu Mar 13 2008 on uwakimon' [ie, built immediately after your patch
was committed], in a TTY.
I'm getting the buggy behavior on Mac OS X in `XEmacs 21.5 (beta28)
"fuki" f4eb31866c38+ [Lucid] (powerpc-apple-darwin8.11.0, Mule) of Mon
Apr 7 2008 on chibi.local' on Apple's X server. XEmacs is up to date
to 279739019e5c.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:06 a.m.
Stephen J. Turnbull writes:
I'm getting the buggy behavior on Mac OS X in `XEmacs 21.5
(beta28)
"fuki" f4eb31866c38+ [Lucid] (powerpc-apple-darwin8.11.0, Mule) of Mon
Apr 7 2008 on chibi.local' on Apple's X server. XEmacs is up to date
to 279739019e5c.
NB the conflict between the hg id in the emacs-version output and the
"up-to-date" claim is due to using "./config.status" instead of
"./config.status --recheck". I've since confirmed the result (bug
still present) with "./config.status --recheck && make beta".
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:29 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Apr 6, 2008, at 10:53 AM, Michael Sperber wrote:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> In a quick test, it does *not* fix issue303 for me (but I have not
> done a full rebuild with the patch yet, just a "make").
> [...]
> issue303, [Bug: 21.5-b28] Bogus motion of modeline
I don't see it: For me, the echo area goes to 2 lines and stays there.
The middle modeline creeps up by one but stays there. If nobody
confirms the problem's still there, I intend to close this one.
I haven't been able to get a working build from a checkout yet, but
I'm going to keep trying. Not much luck on the Mac, so I'm going to
try Ubuntu next. I'll let you know if I make any progress.
Thanks for looking into this.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR/oTunEjvBPtnXfVAQJ7pAQAjzCAzl+JGB8NfsCwqZWttK7rbyIzBKAS
4dI0biHzp4lUzAwXTuQCtZEKs3sNkyf8Ka/OU5DrVQNs+PfqNGqceqU27GQNwqlO
O3Cp7cL4RauEoWGONI+0gjR0IdMqYBt3GCka79GUM2OlE7RRQRx1G2mSjDsTYtv2
1+DTrniz5Bg=
=/r8S
-----END PGP SIGNATURE-----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:59 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> さんは書きました:
Michael Sperber writes:
>
> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>
> > In a quick test, it does *not* fix issue303 for me (but I have not
> > done a full rebuild with the patch yet, just a "make").
> > [...]
> > issue303, [Bug: 21.5-b28] Bogus motion of modeline
>
> I don't see it: For me, the echo area goes to 2 lines and stays there.
If you don't get the echo area to return to one line height, you're
not executing the recipe correctly, or perhaps you've customized
`resize-minibuffer-window-exactly' to nil.
> The middle modeline creeps up by one but stays there. If nobody
> confirms the problem's still there, I intend to close this one.
For me the middle modeline keeps creeping up and the buffer
on top of it becomes smaller and smaller until it is only
one line high.
--
Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:31 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Apr 22, 2008, at 1:59 PM, Mike FABIAN wrote:
"Stephen J. Turnbull" <stephen(a)xemacs.org> さんは書きました:
> Michael Sperber writes:
>>
>> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>
>>> In a quick test, it does *not* fix issue303 for me (but I have not
>>> done a full rebuild with the patch yet, just a "make").
>>> [...]
>>> issue303, [Bug: 21.5-b28] Bogus motion of modeline
>>
>> I don't see it: For me, the echo area goes to 2 lines and stays
>> there.
>
> If you don't get the echo area to return to one line height, you're
> not executing the recipe correctly, or perhaps you've customized
> `resize-minibuffer-window-exactly' to nil.
>
>> The middle modeline creeps up by one but stays there. If nobody
>> confirms the problem's still there, I intend to close this one.
For me the middle modeline keeps creeping up and the buffer
on top of it becomes smaller and smaller until it is only
one line high.
I'm sorry I have not had time to test the fix, but that's exactly the
behavior I've seen in b28.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBSA4u/XEjvBPtnXfVAQJLAQQAlQkv7KGS/Wi65bNxTJuuPs2tl/HZupzG
NXF/iSLoBg7lPerZEd+vh2nJx4o5+GzUbRKYvDCJVeNK+pLXCkOjdLWtytugnzdF
NveWAX8T/C4GCBgJZnEOGk0ZPbYTaCRHXwnSwLUHopfY9keHtYPNlRDQhesINH5k
yrdZz8Ij0+4=
=UDa5
-----END PGP SIGNATURE-----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:33 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
If you don't get the echo area to return to one line height,
you're
not executing the recipe correctly, or perhaps you've customized
`resize-minibuffer-window-exactly' to nil.
Indeed I had.
First, why is *any* permanent motion OK? If you want to push
priority
down to zero or unassign yourself from the bug, that's one thing, but
but this is not backward compatible (assuming default settings), and
there's no specification that says this is desirable behavior or what
to expect in slightly different situations.
I didn't want to disassociate myself from the problem, just make sure
that its presence is confirmed if it's still there.
Anyway, I've figured out what caused this. (It has nothing to do with
window configurations.) The problem is that bumping the minibuffer size
up and then down again isn't symmetic. You can try this out by opening
up a frame on *scratch*, splitting it, and then doing this there:
(enlarge-window 1 nil (minibuffer-window (selected-frame)))
(enlarge-window -1 nil (minibuffer-window (selected-frame)))
The attached patch fixes this for me. You still (potentially) get a
small bit of permanent motion due to the rounding to the default text
height, but it stabilizes after the first roundtrip. If there are no
objections, I'll push this on Tuesday or so.
2008-04-26 Mike Sperber <mike(a)xemacs.org>
* window.c (set_window_pixsize): Round up when we're shrinking,
down when we're growing * to make sure that pairs of grow / shrink
meant to * cancel out actually do cancel out. This fixes a
problem with `resize-minibuffer-mode' where successive grow/shrink
actions are meant to cancel out, but previously didn't.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
diff --git a/src/window.c b/src/window.c
--- a/src/window.c
+++ b/src/window.c
＠＠ -3601,7 +3601,17 ＠＠
/* All but the last window should have a height which is
a multiple of the default line height. */
if (!NILP (c->next))
- pos = (pos / line_size) * line_size;
+ {
+ /*
+ * Round up when we're shrinking, down when we're growing
+ * to make sure that pairs of grow / shrink meant to
+ * cancel out actually do cancel out.
+ */
+ if (pixel_adj_left < 0)
+ pos = ((pos + line_size -1) / line_size) * line_size;
+ else
+ pos = (pos / line_size) * line_size;
+ }
/* Avoid confusion: don't delete child if it becomes too small */
set_window_pixsize (child, pos + first - last_pos, 1, set_height);
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:20 p.m.
Michael Sperber <sperber(a)deinprogramm.de> さんは書きました:
Anyway, I've figured out what caused this. (It has nothing to do
with
window configurations.) The problem is that bumping the minibuffer size
up and then down again isn't symmetic. You can try this out by opening
up a frame on *scratch*, splitting it, and then doing this there:
(enlarge-window 1 nil (minibuffer-window (selected-frame)))
(enlarge-window -1 nil (minibuffer-window (selected-frame)))
Yes, I can reproduce the problem using that procedure.
The attached patch fixes this for me. You still (potentially) get a
small bit of permanent motion due to the rounding to the default text
height, but it stabilizes after the first roundtrip. If there are no
objections, I'll push this on Tuesday or so.
I’ll test your patch now …
--
Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:33 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Apr 26, 2008, at 10:33 AM, Michael Sperber wrote:
(enlarge-window 1 nil (minibuffer-window (selected-frame)))
(enlarge-window -1 nil (minibuffer-window (selected-frame)))
The attached patch fixes this for me. You still (potentially) get a
small bit of permanent motion due to the rounding to the default text
height, but it stabilizes after the first roundtrip. If there are no
objections, I'll push this on Tuesday or so.
Mike, with both your test and some real-world use, it looks like this
patch fixes the problem for me (in 21.5.28). Thank you so much!
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBSBXEDHEjvBPtnXfVAQKUcgP9F0vHiTPVKWqIPpqBQNMVCsdDtz4D1GhS
+ISCBqYBX+QqhirgB/FqmVuyokjtv7CKPzJ0gG80osh7ccjf8eGmz1jQ8jfCYZ7j
BcWSd+6wipbA1+b5b71sU6Q2L5XHQRSJ8A0p/LmpPy7bmsRGkPjbov+EUEDa5mLc
8twdaLuorrk=
=aQbm
-----END PGP SIGNATURE-----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:15 p.m.
Mike FABIAN <mfabian(a)suse.de> さんは書きました:
Michael Sperber <sperber(a)deinprogramm.de> さんは書きました:
> Anyway, I've figured out what caused this. (It has nothing to do with
> window configurations.) The problem is that bumping the minibuffer size
> up and then down again isn't symmetic. You can try this out by opening
> up a frame on *scratch*, splitting it, and then doing this there:
>
> (enlarge-window 1 nil (minibuffer-window (selected-frame)))
> (enlarge-window -1 nil (minibuffer-window (selected-frame)))
Yes, I can reproduce the problem using that procedure.
> The attached patch fixes this for me. You still (potentially) get a
> small bit of permanent motion due to the rounding to the default text
> height, but it stabilizes after the first roundtrip. If there are no
> objections, I'll push this on Tuesday or so.
I’ll test your patch now …
Yes, it helps. Thank you!
--
Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:22 p.m.
New subject: [A21.5] Re: commit: Fix window-configuration problem.
APPROVE 21.5
Does 21.4 need a similar patch?
Michael Sperber writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> First, why is *any* permanent motion OK?
Anyway, I've figured out what caused this. (It has nothing to do with
window configurations.)
OK, thanks for confirming this.
The problem is that bumping the minibuffer size
up and then down again isn't symmetic. You can try this out by opening
up a frame on *scratch*, splitting it, and then doing this there:
(enlarge-window 1 nil (minibuffer-window (selected-frame)))
(enlarge-window -1 nil (minibuffer-window (selected-frame)))
The attached patch fixes this for me. You still (potentially) get a
small bit of permanent motion due to the rounding to the default text
height, but it stabilizes after the first roundtrip.
I agree this is a fix; enlarge-window should not check if it's
restoring a window configuration. resize-minibuffer-mode may be buggy
or need a feature to make its behavior more predictable, but that's
not a problem with the window configuration code (including
enlarge-window).
If there are no
objections, I'll push this on Tuesday or so.
2008-04-26 Mike Sperber <mike(a)xemacs.org>
* window.c (set_window_pixsize): Round up when we're shrinking,
down when we're growing * to make sure that pairs of grow / shrink
meant to * cancel out actually do cancel out. This fixes a
problem with `resize-minibuffer-mode' where successive grow/shrink
actions are meant to cancel out, but previously didn't.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5836
days inactive
5882
days old
11 comments
4 participants
participants (4)
-
Barry Warsaw -
Michael Sperber -
Mike FABIAN -
Stephen J. Turnbull