BUG: Incorrect point after window splitting

BUG: Incorrect point after window splitting

[David Hedbor]

Hello.

Third time I write to report this bug, which is driving me crazy
(almost far enough to me to look for a new mailprogram).

The bug: When opening a message for the first time in a buffer which
hash a number of emails (required number probably depends on the size
of the message buffer), the point of the cursor in the message list is
changed. This means that when I go to press reply, I reply to another
message.

This is an example of the point before and after:

Before: 2925
After: 571

I have a couple of screenshots too at:

http://david.hedbor.org/tmp/before.gif
http://david.hedbor.org/tmp/after.gif

Notice how the point is in a completely different place after pressing
RET to open the message.

I tried debugging it but when the debugger window is open, the problem
doesn't seem to appear. :-(

Am I _really_ the only one with this problem? Is it an xemacs bug?
This bug wasn't always where but I don't remember exactly when it
appeared. 

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Kansas state law requires pedestrians crossing the highways at night to
wear tail lights.

Re: BUG: Incorrect point after window splitting

[David Hedbor]

David Hedbor <david@hedbor.org> writes:

> Am I _really_ the only one with this problem? Is it an xemacs bug?
> This bug wasn't always where but I don't remember exactly when it
> appeared. 

I figured out when it broke - with gnus-win.el version 5.7. When using
5.6, everything works as it should. Now it should be easier for you
list gods to figure out what broke.


-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Never make anything simple and efficient when a way can be found to
make it complex and wonderful.

Re: BUG: Incorrect point after window splitting

[Lars Magne Ingebrigtsen]

David Hedbor <david@hedbor.org> writes:

> The bug: When opening a message for the first time in a buffer which
> hash a number of emails (required number probably depends on the size
> of the message buffer), the point of the cursor in the message list is
> changed. This means that when I go to press reply, I reply to another
> message.

I am unable to reproduce this bug.  Does anybody else see this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: BUG: Incorrect point after window splitting

[David Hedbor]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> David Hedbor <david@hedbor.org> writes:
> 
> > The bug: When opening a message for the first time in a buffer which
> > hash a number of emails (required number probably depends on the size
> > of the message buffer), the point of the cursor in the message list is
> > changed. This means that when I go to press reply, I reply to another
> > message.
> 
> I am unable to reproduce this bug.  Does anybody else see this?

I'm thinking I should try with a newer version of xemacs (what did you
try with?). When using gnus-win.el 5.6, everything does work perfectly
however. I don't know if that can give you any idea what might be
wrong. Sometime when I get time, I might sit down and try to figure
out why it happens. The total difference in lines is +11 -9, so it's
not exactly a lot of changes.

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Rotten wood cannot be carved.
		-- Confucius, "Analects", Book 5, Ch. 9

Re: BUG: Incorrect point after window splitting

[Lars Magne Ingebrigtsen]

David Hedbor <david@hedbor.org> writes:

> I'm thinking I should try with a newer version of xemacs (what did you
> try with?).

XEmacs 21.2  (beta16) "Sumida" [Lucid] (i686-pc-linux, Mule) of Sun Oct 17 1999 on quimbies.gnus.org

Old as molasses.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: BUG: Incorrect point after window splitting

[Björn Torkelsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> David Hedbor <david@hedbor.org> writes:
> 
> > The bug: When opening a message for the first time in a buffer which
> > hash a number of emails (required number probably depends on the size
> > of the message buffer), the point of the cursor in the message list is
> > changed. This means that when I go to press reply, I reply to another
> > message.
> 
> I am unable to reproduce this bug.  Does anybody else see this?

I see it, with a CVS updated gnus a an hour ago, and xemacs 21.2 beta 32
CVS updated about two weeks ago.

I enter a group with a lot of ticked articles, by hitting 'enter'. Then I
press 'n' to go to the first unread article. I end up reading the new
unread article, but with the cursor at a completly different place. 

/torkel

Re: BUG: Incorrect point after window splitting

[Daniel Pittman]

On 20 Apr 2000, Björn Torkelsson <torkel@hpc2n.umu.se> wrote:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
>> David Hedbor <david@hedbor.org> writes:
>> 
>> > The bug: When opening a message for the first time in a buffer
>> > which hash a number of emails (required number probably depends on
>> > the size of the message buffer), the point of the cursor in the
>> > message list is changed. This means that when I go to press reply,
>> > I reply to another message.
>> 
>> I am unable to reproduce this bug.  Does anybody else see this?
> 
> I see it, with a CVS updated gnus a an hour ago, and xemacs 21.2 beta
> 32 CVS updated about two weeks ago.
> 
> I enter a group with a lot of ticked articles, by hitting 'enter'. 
> Then I press 'n' to go to the first unread article. I end up reading
> the new unread article, but with the cursor at a completly different
> place.

Mmmm. I see this also.

The cause of this lossage is the value of 'window-start' for the various
gnus display buffers when certain things are done -
'delete-other-windows' for a start.

XEmacs seems to optimize this such that the value is not up to date for
what *should* be in the buffer at the time of the various calls, rather
what *was* there prior to the action.

The DOC for 'delete-other-windows' notes that 'window-start' should be
set to something sane before calling.

I think. This is as far as I got looking at the issue, and that was a
few weeks ago now. Ain't it grand when life is *so* full? :/

Hope that helps someone find this,
        Daniel

-- 
Our quarrel with the world is an echo of the 
endless quarrel proceeding within us.
        -- Eric Hoffer

Re: BUG: Incorrect point after window splitting

[Lars Magne Ingebrigtsen]

torkel@hpc2n.umu.se (Björn Torkelsson) writes:

> I enter a group with a lot of ticked articles, by hitting 'enter'. Then I
> press 'n' to go to the first unread article. I end up reading the new
> unread article, but with the cursor at a completly different place. 

Does setting `gnus-xmas-force-redisplay' to t make any difference?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: BUG: Incorrect point after window splitting

[Björn Torkelsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> torkel@hpc2n.umu.se (Björn Torkelsson) writes:
> 
> > I enter a group with a lot of ticked articles, by hitting 'enter'. Then I
> > press 'n' to go to the first unread article. I end up reading the new
> > unread article, but with the cursor at a completly different place. 
> 
> Does setting `gnus-xmas-force-redisplay' to t make any difference?

Nope... but if I set it to nil the curser end up at the right place.. 

/torkel

Re: BUG: Incorrect point after window splitting

[Lars Magne Ingebrigtsen]

torkel@hpc2n.umu.se (Björn Torkelsson) writes:

> > Does setting `gnus-xmas-force-redisplay' to t make any difference?
> 
> Nope... but if I set it to nil the curser end up at the right place.. 

That's really odd, because that should be the default value, I'd have
thought. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: BUG: Incorrect point after window splitting

[Björn Torkelsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> torkel@hpc2n.umu.se (Björn Torkelsson) writes:
> 
> > > Does setting `gnus-xmas-force-redisplay' to t make any difference?
> > 
> > Nope... but if I set it to nil the curser end up at the right place.. 
> 
> That's really odd, because that should be the default value, I'd have
> thought. 

It is... I think... For some to me unknown reason I did change it with
customize... don't know when, don't know why... 

/torkel