jit-lock called at EOB?

jit-lock called at EOB?

[Stefan Monnier]

The recent problems of "looping in jit-lock / redisplay" seem to be caused
by the fact that every redisplay will call jit-lock at EOB because the
text-property value of `fontified' at EOB is always nil (this is because
get-text-property treats requests at EOB specially: there is no char there,
so there can't be a property either, but instead of signalling an error it
returns nil).

I've worked around this problem now in jit-lock by ignoring requests to
fontify empty regions of text, but I believe the real bug is in the C code
which shouldn't call jit-lock at all.  So I suggest the patch below.

Any objection?


        Stefan


--- xdisp.c	22 sep 2006 11:15:42 -0400	1.1122
+++ xdisp.c	28 sep 2006 10:28:50 -0400	
@@ -3246,7 +3246,9 @@
       && !NILP (Vrun_hooks)
       && (pos = make_number (IT_CHARPOS (*it)),
 	  prop = Fget_char_property (pos, Qfontified, Qnil),
-	  NILP (prop)))
+	  /* Ignore the special cased nil value always present at EOB since
+	     no amount of fontifying will be able to change it.  */
+	  NILP (prop) && IT_CHARPOS (*it) < Z))
     {
       int count = SPECPDL_INDEX ();
       Lisp_Object val;

Re: jit-lock called at EOB?

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The recent problems of "looping in jit-lock / redisplay" seem to be caused
> by the fact that every redisplay will call jit-lock at EOB because the
> text-property value of `fontified' at EOB is always nil (this is because
> get-text-property treats requests at EOB specially: there is no char there,
> so there can't be a property either, but instead of signalling an error it
> returns nil).
>
> I've worked around this problem now in jit-lock by ignoring requests to
> fontify empty regions of text, but I believe the real bug is in the C code
> which shouldn't call jit-lock at all.  So I suggest the patch below.
>
> Any objection?

Looks good to me.

>
>
>         Stefan
>
>
> --- xdisp.c	22 sep 2006 11:15:42 -0400	1.1122
> +++ xdisp.c	28 sep 2006 10:28:50 -0400	
> @@ -3246,7 +3246,9 @@
>        && !NILP (Vrun_hooks)
>        && (pos = make_number (IT_CHARPOS (*it)),
>  	  prop = Fget_char_property (pos, Qfontified, Qnil),
> -	  NILP (prop)))
> +	  /* Ignore the special cased nil value always present at EOB since
> +	     no amount of fontifying will be able to change it.  */
> +	  NILP (prop) && IT_CHARPOS (*it) < Z))
>      {
>        int count = SPECPDL_INDEX ();
>        Lisp_Object val;

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

Re: jit-lock called at EOB?

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The recent problems of "looping in jit-lock / redisplay" seem to be caused
> by the fact that every redisplay will call jit-lock at EOB because the
> text-property value of `fontified' at EOB is always nil (this is because
> get-text-property treats requests at EOB specially: there is no char there,
> so there can't be a property either, but instead of signalling an error it
> returns nil).
>
> I've worked around this problem now in jit-lock by ignoring requests to
> fontify empty regions of text, but I believe the real bug is in the C code
> which shouldn't call jit-lock at all.  So I suggest the patch below.
>
> Any objection?

[Please ignore previous _incomplete_ message ...]

Looks good to me.

But I would write it like this, since there is no reason to
lookup the property at eob:


*** xdisp.c	20 Sep 2006 10:53:53 +0200	1.1122
--- xdisp.c	29 Sep 2006 13:15:14 +0200	
***************
*** 3244,3249 ****
--- 3244,3252 ----
        && it->s == NULL
        && !NILP (Vfontification_functions)
        && !NILP (Vrun_hooks)
+       /* Ignore the special cased nil value always present at EOB since
+ 	 no amount of fontifying will be able to change it.  */
+       && IT_CHARPOS (*it) < Z
        && (pos = make_number (IT_CHARPOS (*it)),
  	  prop = Fget_char_property (pos, Qfontified, Qnil),
  	  NILP (prop)))



>
> --- xdisp.c	22 sep 2006 11:15:42 -0400	1.1122
> +++ xdisp.c	28 sep 2006 10:28:50 -0400	
> @@ -3246,7 +3246,9 @@
>        && !NILP (Vrun_hooks)
>        && (pos = make_number (IT_CHARPOS (*it)),
>  	  prop = Fget_char_property (pos, Qfontified, Qnil),
> -	  NILP (prop)))
> +	  /* Ignore the special cased nil value always present at EOB since
> +	     no amount of fontifying will be able to change it.  */
> +	  NILP (prop) && IT_CHARPOS (*it) < Z))
>      {
>        int count = SPECPDL_INDEX ();
>        Lisp_Object val;

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

Re: jit-lock called at EOB?

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The recent problems of "looping in jit-lock / redisplay" seem to be
> caused by the fact that every redisplay will call jit-lock at EOB
> because the text-property value of `fontified' at EOB is always nil
> (this is because get-text-property treats requests at EOB specially:
> there is no char there, so there can't be a property either, but
> instead of signalling an error it returns nil).

Wouldn't it make sense if rear-sticky properties of the last character
in the buffer would be returned by
(get-text-property (point-max))
?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: jit-lock called at EOB?

[Stefan Monnier]

>> The recent problems of "looping in jit-lock / redisplay" seem to be caused
>> by the fact that every redisplay will call jit-lock at EOB because the
>> text-property value of `fontified' at EOB is always nil (this is because
>> get-text-property treats requests at EOB specially: there is no char there,
>> so there can't be a property either, but instead of signalling an error it
>> returns nil).
>> 
>> I've worked around this problem now in jit-lock by ignoring requests to
>> fontify empty regions of text, but I believe the real bug is in the C code
>> which shouldn't call jit-lock at all.  So I suggest the patch below.
>> 
>> Any objection?

> [Please ignore previous _incomplete_ message ...]

> Looks good to me.

> But I would write it like this, since there is no reason to
> lookup the property at eob:

I figured that this test is the least discriminating one, so it's better to
do it last.  Doing it before the call to Fget_text_property will only save
us a call to Fget_text_property in the rare case of EOB.
The way I wrote it, it only adds a test in the case where jit-lock would
normally be invoked, so the performance impact is clearly minimal.

Of course, in the end I'm pretty sure neither alternative will make
any difference.


        Stefan

Re: jit-lock called at EOB?

[Richard Stallman]

I agree with the idea of your change, but you may as well test
IT_CHARPOS (*it)) < Z before calling Fget_char_property.

Re: jit-lock called at EOB?

[Richard Stallman]

    Wouldn't it make sense if rear-sticky properties of the last character
    in the buffer would be returned by
    (get-text-property (point-max))
    ?

No, because get-text-property at other positions does not check
for rear-sticky properties of the preceding character.
This function inquires about the properties of a character.

After the release we could install a function that would return
the properties that would be inherited by a character inserted
at a certain place.

Re: jit-lock called at EOB?

[Stefan Monnier]

> After the release we could install a function that would return
> the properties that would be inherited by a character inserted
> at a certain place.

It's called get_pos_property in the C code.


        Stefan