When are the face text properties actually set?

When are the face text properties actually set?

[jack-mac]

I'm using GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.22.0)
of 2011-03-04 on roseapple, modified by Debian

I start "emacs -Q", open any emacs-lisp file which containing more
than
one page of text.  I choose a point (e.g. 2400) which is beyond the
first page and type the following:

	M-: (get-text-property 2400 'face) RET
        => nil

        M-: (progn (goto-char 2400) (get-text-property 2400 'face))
        => nil

Now, point 2400 is visible.

	M-: (get-text-property 2400 'face) RET
        => font-lock-comment-face

The function get-text-property returns nil only when the point given
as argument has not yet been displayed.

So, I can reproduce it each time I close and reopen the file. (C-x C-v
RET)

Is this normal or is it a bug?


If it's normal, is there any way to force the text properties to be
set the way they will be set when the point is displayed?

I mean: I just want (get-text-property 2400 'face) to return the text
property whether it has already been displayed or not!

I tried the following which works more or less:

        M-: (progn (goto-char 2400) (sit-for 0) (get-text-property
2400 'face))
        => font-lock-comment-face

but, if I use it inside my personal search and replace function, the
text is continuously scrolled all over the file, which is quite
disturbing.

I also tried M-x font-lock-fontify-buffer but it did not change
anything.
And there is no lazy-font anymore in the emacs I use.

Thanks in advance

)jack(

Re: When are the face text properties actually set?

[Stefan Monnier]

> Is this normal or is it a bug?

It's normal: this is handled by jit-lock which adds the property on the
fly before a chunk of text is displayed.

> If it's normal, is there any way to force the text properties to be
> set the way they will be set when the point is displayed?

Yes, you can use something like jit-lock-fontify-now.

> I mean: I just want (get-text-property 2400 'face) to return the text
> property whether it has already been displayed or not!

> I tried the following which works more or less:

>         M-: (progn (goto-char 2400) (sit-for 0) (get-text-property
> 2400 'face))
>         => font-lock-comment-face

Rather than check the `face' property for `font-lock-comment-face' you
should check the output of (syntax-ppss), which also has the advantage
of not depending on highlighting (so you don't need to fiddle with
jit-lock or worry about those users who disable font-lock).


        Stefan

Re: When are the face text properties actually set?

[jack-mac]

Thanks a lot, Stefan, for your precious answers!

On 13 juin, 17:18, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> It's normal: this is handled by jit-lock which adds the property on the
> fly before a chunk of text is displayed.

I did not know the jit-lock system!
When I do "ema
Can you tell me why, when

>
> > If it's normal, is there any way to force the text properties to be
> > set the way they will be set when the point is displayed?
>
> Yes, you can use something like jit-lock-fontify-now.



>
> > I mean: I just want (get-text-property 2400 'face) to return the text
> > property whether it has already been displayed or not!
> > I tried the following which works more or less:
> >         M-: (progn (goto-char 2400) (sit-for 0) (get-text-property
> > 2400 'face))
> >         => font-lock-comment-face
>
> Rather than check the `face' property for `font-lock-comment-face' you
> should check the output of (syntax-ppss), which also has the advantage
> of not depending on highlighting (so you don't need to fiddle with
> jit-lock or worry about those users who disable font-lock).
>
>         Stefan

Re: When are the face text properties actually set?

[jack-mac]

Oops! Sorry for the previous (possibly not deleted) post, sent before
finished.  I should not use emacs shortcuts inside firefox...

Thanks a lot, Stefan, for your precious answers!

On 13 juin, 17:18, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> It's normal: this is handled by jit-lock which adds the property on
> the fly before a chunk of text is displayed.

I did not know jit-mode.  Is it recent?  Does it replace lazy-lock?

When I start "emacs -Q .emacs", for example, I get the following:
M-: jit-lock-mode
=> t
M-: (memq 'jit-lock-mode minor-mode-list)
=> nil

Can you tell me why jit-lock-mode does not appear in the list of minor
modes?

> > If it's normal, is there any way to force the text properties to
> > be set the way they will be set when the point is displayed?
>
> Yes, you can use something like jit-lock-fontify-now

Thanks!  It's very simple and fast enough for my function, but...

> Rather than check the `face' property for `font-lock-comment-face'
> you should check the output of (syntax-ppss), which also has the
> advantage of not depending on highlighting (so you don't need to
> fiddle with jit-lock or worry about those users who disable
> font-lock).

Well, to answer Eli's question (why do I need that), I would say that
checking the text-properties was the solution I imagined to determine
whether the point is inside a string or a comment, for example.

Now, Stefan tells me there is an API to the syntactic parser.

Woah!  It's like opening a door to a rich and exciting new world!

I took a look at syntax-ppss and parse-partial-sexp documentation.
It says it parses *Lisp* syntax.

Is it a bug in the documentation?

Before I go any further in the tests and doc (which is far for being
perfectly clear to me, at first glance!), can you tell me if I can use
it in other modes than emacs-lisp, like C-like modes, for example?

Actually, I'm currently working on shell scripts (in sh-mode[pdksh]).
Does it handle the whole syntax:
"..." '...' `...` {...} [...] [[...]] $(...) etc?

Thanks in advance

Re: When are the face text properties actually set?

[Stefan Monnier]

> I did not know jit-mode.  Is it recent?

It was brand new in Emacs-21.

> Does it replace lazy-lock?

Yup, that one was marked obsolete in Emacs-22.

> Can you tell me why jit-lock-mode does not appear in the list of minor
> modes?

Because, even though it started as a minor-mode (like lazy-lock), it's
not a minor mode any more.  It's a library that can optionally be used
by font-lock and by other packages (nlinum.el, nhexl.el, and
glasses-mode).

> I took a look at syntax-ppss and parse-partial-sexp documentation.
> It says it parses *Lisp* syntax.
> Is it a bug in the documentation?

Yes and no: it doesn't know how to parse languages with a syntax more
complex than Lisp's, but it does know how to parse most language's
comments, parentheses, and strings.


        Stefan

Re: When are the face text properties actually set?

[jack-mac]

Ok.  Thanks a lot for your replies.

Re: When are the face text properties actually set?

[Eli Zaretskii]

> From: jack-mac <duthen.mac@gmail.com>
> Date: Wed, 13 Jun 2012 07:32:31 -0700 (PDT)
> 
> I start "emacs -Q", open any emacs-lisp file which containing more
> than
> one page of text.  I choose a point (e.g. 2400) which is beyond the
> first page and type the following:
> 
> 	M-: (get-text-property 2400 'face) RET
>         => nil
> 
>         M-: (progn (goto-char 2400) (get-text-property 2400 'face))
>         => nil
> 
> Now, point 2400 is visible.
> 
> 	M-: (get-text-property 2400 'face) RET
>         => font-lock-comment-face
> 
> The function get-text-property returns nil only when the point given
> as argument has not yet been displayed.
> 
> So, I can reproduce it each time I close and reopen the file. (C-x C-v
> RET)
> 
> Is this normal or is it a bug?

Normal.

> If it's normal, is there any way to force the text properties to be
> set the way they will be set when the point is displayed?

Yes, but it's slow: you need to get the whole buffer fontified by
font-lock.  Normally, Emacs only fontifies the portion of text that is
about to be displayed.

> I tried the following which works more or less:
> 
>         M-: (progn (goto-char 2400) (sit-for 0) (get-text-property
> 2400 'face))
>         => font-lock-comment-face

Yes, because sit-for causes Emacs to prepare the text for display.

Why do you need that?