Ok, here is the bug I have been looking for. Kim, not Jan...

Ok, here is the bug I have been looking for. Kim, not Jan...

[David Kastrup]

With -fno-crossjumping, the real assert came to light.

It is xdisp.c in line 6122:

  /* The function move_it_vertically_backward may move over more
     than the specified y-distance.  If it->w is small, e.g. a
     mini-buffer window, we may end up in front of the window's
     display area.  Start displaying at the start of the line
     containing PT in this case.  */
  if (it.current_y <= 0)
    {
      init_iterator (&it, w, PT, PT_BYTE, NULL, DEFAULT_FACE_ID);
      move_it_vertically_backward (&it, 0);
      xassert (IT_CHARPOS (it) <= PT);
      it.current_y = 0;
    }

I suppose that the reseat_1 in move_it_vertically_backward will move
forward again.  Something like that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> With -fno-crossjumping, the real assert came to light.
>
> It is xdisp.c in line 6122:
>
>   /* The function move_it_vertically_backward may move over more
>      than the specified y-distance.  If it->w is small, e.g. a
>      mini-buffer window, we may end up in front of the window's
>      display area.  Start displaying at the start of the line
>      containing PT in this case.  */
>   if (it.current_y <= 0)
>     {
>       init_iterator (&it, w, PT, PT_BYTE, NULL, DEFAULT_FACE_ID);
>       move_it_vertically_backward (&it, 0);
>       xassert (IT_CHARPOS (it) <= PT);
>       it.current_y = 0;
>     }
>
> I suppose that the reseat_1 in move_it_vertically_backward will move
> forward again.  Something like that.

True.  This can happen if PT is invisible text or in text that is
replaced by an image.  I guess it is related to a bug that I still
have to investigate (see below).

I think you can safely disable the xassert with #if 0 for now.


The bug reveals itself like this:

Suppose you have a window with this context

abc
[     ]
[IMAGE]xyz
[     ]
def

Now, if you place the cursor at 'z' and hit C-a, it moves to 'x'.
Also, M-: (bolp) returns t at that position.

I haven't fully debugged this, but it seems to happen when the text
overlayed by the IMAGE includes or ends with a newline.

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

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> With -fno-crossjumping, the real assert came to light.
>>
>> It is xdisp.c in line 6122:

In my checkout, the xassert is in line 12290.

I have now eliminated that xassert.

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

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> With -fno-crossjumping, the real assert came to light.
>>>
>>> It is xdisp.c in line 6122:
>
> In my checkout, the xassert is in line 12290.

Talk about me being imprecise... probably confused this with another
buffer.

> I have now eliminated that xassert.

Well, I have now eliminated all xasserts on my computer for now, and I
find it highly embarrassing that I have to tell people that want to
test drive Emacs without becoming a debugger-savvy developer that they
have to patch around in the source to get it to workable state.  I
have spent about a week for a total of 4 of them (the last being very
elusive, partly due to my stupidity) that basically were of the "well,
if we get a test case where Emacs does not scroll in the right
direction, it may also possibly trigger the assert, and this is
something that we may or may not do something about before the
release" category.  It has been a very unproductive waste of time for
me.

It would be one thing if I could see that it does in any manner
improve our chance of getting _valuable_ feedback (instead of "it
crashed, and even had I been running it in a debugger, the screen
would no longer be updated to show what I had been doing" kind of
reports).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> It would be one thing if I could see that it does in any manner
> improve our chance of getting _valuable_ feedback (instead of "it
> crashed, and even had I been running it in a debugger, the screen
> would no longer be updated to show what I had been doing" kind of
> reports).

Often, you can enter `ff' to refresh the emacs frame even
after it has crashed.

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

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Miles Bader]

On Wed, 02 Mar 2005 00:52:13 +0100, David Kastrup <dak@gnu.org> wrote:
> I find it highly embarrassing that I have to tell people that want to
> test drive Emacs without becoming a debugger-savvy developer

Why do you find it "embarrassing"?  Is it surprising to these people
that a develop tree is optimized for ... development?

It is certainly possible for Richard to decide that the default state
of the CVS trunk should be optimized for random users who want to
check out Emacs, and not for people interested in helping find bugs.

But I think it should an explicit decision to that effect.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[David Kastrup]

Miles Bader <snogglethorpe@gmail.com> writes:

> On Wed, 02 Mar 2005 00:52:13 +0100, David Kastrup <dak@gnu.org> wrote:

>> I find it highly embarrassing that I have to tell people that want
>> to test drive Emacs without becoming a debugger-savvy developer
>
> Why do you find it "embarrassing"?

Because there is no other usable Emacs to be had?

> Is it surprising to these people that a develop tree is optimized
> for ... development?

It isn't.  This "optimization" has wasted a week for me already, by
triggering non-bugs that were slated to be fixed anyway.

Just because I point out that the external damage we are doing with
this kind of thing is acutely embarrassing and unnecessary does not
mean that it not also impedes development internally.

> It is certainly possible for Richard to decide that the default
> state of the CVS trunk should be optimized for random users who want
> to check out Emacs, and not for people interested in helping find
> bugs.

You conveniently ignore that I already explained several times that
this setting in the current situation is actively _preventing_ fixing
the kind of "bugs" that get triggered by it.

Just that I also point out that shooting others in the foot is not
going to make us popular does not mean that I consider shooting
ourselves in the foot a great pastime.

> But I think it should an explicit decision to that effect.

I was of the opinion I was arguing just for that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Kim F. Storm]

Miles Bader <snogglethorpe@gmail.com> writes:

>
> But I think it should an explicit decision to that effect.

I don't remember an explicit decision was made before you enabled the
xasserts.  So why is an explicit decision needed to disable them?

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

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Miles Bader]

On Wed, 02 Mar 2005 12:44:27 +0100, Kim F. Storm <storm@cua.dk> wrote:
> > But I think it should an explicit decision to that effect.
> 
> I don't remember an explicit decision was made before you enabled the
> xasserts.  So why is an explicit decision needed to disable them?

I think an explicit decision should be made one way or the other.

At the time I enabled it, that was not clear the degree to which it
would be a contentious issue (I had been using it personally for ages
without any notable problems, and I _did_ ask before I enabled it by
default) -- however, now it is.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Kim F. Storm]

Miles Bader <snogglethorpe@gmail.com> writes:

> I think an explicit decision should be made one way or the other.

Based on the fact that _I_ don't have the necessary time to debug more
silly xasserts, _I_ made the explicit decision to disable them.

>
> At the time I enabled it, that was not clear the degree to which it
> would be a contentious issue (I had been using it personally for ages
> without any notable problems, and I _did_ ask before I enabled it by
> default) -- however, now it is.

-- and now it isn't.

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

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Miles Bader <snogglethorpe@gmail.com> writes:
>
>> I think an explicit decision should be made one way or the other.
>
> Based on the fact that _I_ don't have the necessary time to debug more
> silly xasserts, _I_ made the explicit decision to disable them.
>
>>
>> At the time I enabled it, that was not clear the degree to which it
>> would be a contentious issue (I had been using it personally for ages
>> without any notable problems, and I _did_ ask before I enabled it by
>> default) -- however, now it is.
>
> -- and now it isn't.

I'd have prefered to solve conflicts other than by battling commits,
even though it is more than obvious that this change at least suits
me.  At the moment, rather few developers have voiced an opinion in
this matter.  It will clearly be a good idea at the time Kim thinks
that the changes in the display engine have reached a state where no
major overhauls are due until the release, and where the remaining
assertions are strictly consistent with the expected behavior, that a
larger _developer_ base will run with xasserts switch on.  And I agree
with Miles that it would be beneficial if assertions for which this is
not clear in the current situation get outcommented or moved to a
different class of assertions for now, so that one has the possibility
of running with assertions switched on while getting useful
information.

Assertions should stay in a usable state, that much I agree with
Miles.  I don't agree with his opinion that it is a good idea to
enable them in HEAD now.  After we branch for release, I would not
object.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Miles Bader]

On Thu, 03 Mar 2005 00:10:35 +0100, Kim F. Storm <storm@cua.dk> wrote:
> Miles Bader <snogglethorpe@gmail.com> writes:
> 
> > I think an explicit decision should be made one way or the other.
> 
> Based on the fact that _I_ don't have the necessary time to debug more
> silly xasserts, _I_ made the explicit decision to disable them.

So you're gonna go the "childish commit wars" route?

You're a good hacker in many ways Kim, but this is just stupid.  The
Emacs hacker community is generally above that sort of thing (unlike
many other projects); please let's keep it that way.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Kim F. Storm]

Miles Bader <snogglethorpe@gmail.com> writes:

> On Thu, 03 Mar 2005 00:10:35 +0100, Kim F. Storm <storm@cua.dk> wrote:
>> Miles Bader <snogglethorpe@gmail.com> writes:
>> 
>> > I think an explicit decision should be made one way or the other.
>> 
>> Based on the fact that _I_ don't have the necessary time to debug more
>> silly xasserts, _I_ made the explicit decision to disable them.
>
> So you're gonna go the "childish commit wars" route?

Childish or not, I don't have time for 

a) discussing this issue further
b) debugging more of those "silly asserts".


> You're a good hacker in many ways Kim, but this is just stupid.  

I agree.

>                                                                  The
> Emacs hacker community is generally above that sort of thing (unlike
> many other projects); please let's keep it that way.

Sure.


In any case, the change I made allows you to easily turn on
asserts, e.g.:

/configure CFLAGS="-g -O0 -DXASSERTS=1"

If somebody would refine that to

/configure --with-asserts

it would be great!!


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

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Jan D.]

Kim F. Storm wrote:

>/configure CFLAGS="-g -O0 -DXASSERTS=1"
>
>If somebody would refine that to
>
>/configure --with-asserts
>
>it would be great!!
>  
>

./configure --enable-asserts

now adds -DXASSERTS=1 to cflags.

    Jan D.

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[Kim F. Storm]

"Jan D." <jan.h.d@swipnet.se> writes:

> Kim F. Storm wrote:
>
>>/configure CFLAGS="-g -O0 -DXASSERTS=1"
>>
>>If somebody would refine that to
>>
>>/configure --with-asserts
>>
>>it would be great!!
>>  
>>
>
> ./configure --enable-asserts
>
> now adds -DXASSERTS=1 to cflags.

Thank you!

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