Re: [miles@lsi.nec.co.jp: redisplay abort if GLYPH_DEBUG turned on]

Re: [miles@lsi.nec.co.jp: redisplay abort if GLYPH_DEBUG turned on]

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> There are other places which set stop_charpos to 0, so
> there is IT_CHARPOS <= stop_charpos is not an invariant.
>
> So Miles' change to the xassert is ok.  But the comment need to be modified 
> as well. 

The thing that makes me nervous is that there seem to also be other
similar xasserts, e.g. [xdisp.c:2727]:

  xassert (STRINGP (it->string)
	   || (it->stop_charpos >= BEGV
	       && it->stop_charpos >= IT_CHARPOS (*it)));

and [xdisp.c:4068]:

      xassert (it->stop_charpos >= BEGV
	       && it->stop_charpos <= it->end_charpos);

implying that there _are_ some sorts of rules for stop_charpos, but I
have no idea what they are.  [I haven't had any crashes involving these
other xasserts.]

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: [miles@lsi.nec.co.jp: redisplay abort if GLYPH_DEBUG turned on]

[Richard Stallman]

    > There are other places which set stop_charpos to 0, so
    > there is IT_CHARPOS <= stop_charpos is not an invariant.

    The thing that makes me nervous is that there seem to also be other
    similar xasserts, e.g. [xdisp.c:2727]:

It's good to be nervous when you see something like that.

Looking at the places that set stop_charpos to 0, I see that they
usually also set it->string to a string.  Here's one possible
exception in reseat_to_string,

  else
    {
      it->s = s;
      it->string = Qnil;

but it sets it->s instead.

The only other exception is the newly added code in set_iterator_to_next.
So I think that setting stop_charpos to 0 is not the right way to
do the job there.

Re: [miles@lsi.nec.co.jp: redisplay abort if GLYPH_DEBUG turned on]

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
>> There are other places which set stop_charpos to 0, so
>> there is IT_CHARPOS <= stop_charpos is not an invariant.
>>
>> So Miles' change to the xassert is ok.  But the comment need to be modified 
>> as well. 
>
> The thing that makes me nervous is that there seem to also be other
> similar xasserts, e.g. [xdisp.c:2727]:
>
>   xassert (STRINGP (it->string)
> 	   || (it->stop_charpos >= BEGV
> 	       && it->stop_charpos >= IT_CHARPOS (*it)));
>
> and [xdisp.c:4068]:
>
>       xassert (it->stop_charpos >= BEGV
> 	       && it->stop_charpos <= it->end_charpos);
>
> implying that there _are_ some sorts of rules for stop_charpos, but I
> have no idea what they are.  [I haven't had any crashes involving these
> other xasserts.]

You may be right -- perhaps there is a different way to fix the original
problem...   I will look into it.

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

Re: [miles@lsi.nec.co.jp: redisplay abort if GLYPH_DEBUG turned on]

[Kim F. Storm]

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

> Miles Bader <miles@lsi.nec.co.jp> writes:
>
>> storm@cua.dk (Kim F. Storm) writes:
>>> There are other places which set stop_charpos to 0, so
>>> there is IT_CHARPOS <= stop_charpos is not an invariant.
>>>
>>> So Miles' change to the xassert is ok.  But the comment need to be modified 
>>> as well. 
>>
>> The thing that makes me nervous is that there seem to also be other
>> similar xasserts, e.g. [xdisp.c:2727]:
>>
>>   xassert (STRINGP (it->string)
>> 	   || (it->stop_charpos >= BEGV
>> 	       && it->stop_charpos >= IT_CHARPOS (*it)));
>>
>> and [xdisp.c:4068]:
>>
>>       xassert (it->stop_charpos >= BEGV
>> 	       && it->stop_charpos <= it->end_charpos);
>>
>> implying that there _are_ some sorts of rules for stop_charpos, but I
>> have no idea what they are.  [I haven't had any crashes involving these
>> other xasserts.]
>
> You may be right -- perhaps there is a different way to fix the original
> problem...   I will look into it.

I just installed a different fix for the original problem.
So stop_charpos is no longer set to 0 outside strings.

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