Best way to detect font-lock mode is on?

Best way to detect font-lock mode is on?

[Tim X]

Just wanting to know what people would suggest as the best way to detect
if font-lock mode is enabled. 

I have two functions I use in a mode to determine if the point is
currently within a comment or a string. If font-lock mode is enabled,
this is quite a fast operation as I can just test the text property.
However, if font-lock is not enabled, I need to do some parsing to try
and determine whether point is on a comment or string. I have defined
two functions i.e. 

(defun pde-in-comment-p ()
  "Returns t if point is within a comment, nil otherwise."
  (if font-lock-defaults
      (eq (get-text-property (point) 'face) 'font-lock-comment-face)
    (nth 4 (parse-partial-sexp (point-min) (point)))))

(defun pde-in-string-p ()
  "Return t if point within a string, nil otherwise."
  (if font-lock-defaults
      (eq (get-text-property (point) 'face) 'font-lock-string-face)
    (nth 3 (parse-partial-sexp (point-min) (point)))))

As you can see, I'm using font-lock-defaults to test whether font-lock
is enabled. Is this the best way to go or is there a more
reliable/better test to use?

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Best way to detect font-lock mode is on?

[Stefan Monnier]

> Just wanting to know what people would suggest as the best way to detect
> if font-lock mode is enabled. 

Wrong question, I suspect.

> I have two functions I use in a mode to determine if the point is
> currently within a comment or a string. If font-lock mode is enabled,

So IIUC the real question is how to determine if you're within a comment
or string.  The answer is (nth 4 (syntax-ppss)) and (nth
3 (syntax-ppss)) respectively (and (nth 8 (syntax-ppss)) if you want to
check whether you're within either of the two).

> As you can see, I'm using font-lock-defaults to test whether font-lock
> is enabled. Is this the best way to go or is there a more
> reliable/better test to use?

Any reason not to use `font-lock-mode'?


        Stefan

Re: Best way to detect font-lock mode is on?

[Tim X]

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

>> Just wanting to know what people would suggest as the best way to detect
>> if font-lock mode is enabled. 
>
> Wrong question, I suspect.
>
>> I have two functions I use in a mode to determine if the point is
>> currently within a comment or a string. If font-lock mode is enabled,
>
> So IIUC the real question is how to determine if you're within a comment
> or string.  The answer is (nth 4 (syntax-ppss)) and (nth
> 3 (syntax-ppss)) respectively (and (nth 8 (syntax-ppss)) if you want to
> check whether you're within either of the two).

Yes, that is how I plan to do it if font-lock is not enabled. I'm
currently experimenting with syntax-ppss and parse-partial-sexp to see
if the cached version can be used reliably or if the uncaching variant
is required and if this has too high a penalty. I have found that with
syntax-ppss, I do get false positives fairly frequently if I don't first
call syntax-pps-flush-cache, which would seem to defeat its benefits
over parse-partial-sexp. These are quite 'heavy' operations and may not
be fast enough if the source file is large enough. As the buffer is
being edited, potentially changing the syntax at random places, it is
difficult to determine when the cache will need to be flushed (though I
have a couple of ideas that may strike an acceptable balance).

>
>> As you can see, I'm using font-lock-defaults to test whether font-lock
>> is enabled. Is this the best way to go or is there a more
>> reliable/better test to use?
>
> Any reason not to use `font-lock-mode'?
>

Only that some people don't like to use font-lock. I wanted the mode's
functionality to be independent of font-lock and not force people to use
it. The tests to determine whether you are in a comment or a string are
used in the calculation of indentation. Using text properties when under
font-lock mode is merely a simple optimisation that will be faster for
large files than parsing the whole file from the beginning. When not
using font-lock, the calculation will be performed using syntax-ppss.
Yes, this does mean that anyone not using font-lock may encounter slower
performance on large files, but at least will probably not be affected
with small/medium sized ones. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Best way to detect font-lock mode is on?

[Stefan Monnier]

> Yes, that is how I plan to do it if font-lock is not enabled. I'm
> currently experimenting with syntax-ppss and parse-partial-sexp to see
> if the cached version can be used reliably or if the uncaching variant
> is required and if this has too high a penalty. I have found that with
> syntax-ppss, I do get false positives fairly frequently if I don't first
> call syntax-pps-flush-cache, which would seem to defeat its benefits
> over parse-partial-sexp.

font-lock uses syntax-ppss, so if syntax-ppss is wrong, font-lock should
be wrong as well.

> As the buffer is being edited, potentially changing the syntax at
> random places, it is difficult to determine when the cache will need
> to be flushed (though I have a couple of ideas that may strike an
> acceptable balance).

syntax-ppss is supposed to automatically flush the (relevant part of)
the cache after any buffer modification.  The only exceptions are when
the buffer is modified in a context where inhibit-modification-hooks is
set (e.g. font-lock-syntactic-keywords).

>>> As you can see, I'm using font-lock-defaults to test whether font-lock
>>> is enabled. Is this the best way to go or is there a more
>>> reliable/better test to use?
>> Any reason not to use `font-lock-mode'?
> Only that some people don't like to use font-lock. I wanted the mode's
> functionality to be independent of font-lock and not force people to use
> it.

No, I mean to use the variable `font-lock-mode' rather than
`font-lock-defaults'.


        Stefan

Re: Best way to detect font-lock mode is on?

[Tim X]

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

>> Yes, that is how I plan to do it if font-lock is not enabled. I'm
>> currently experimenting with syntax-ppss and parse-partial-sexp to see
>> if the cached version can be used reliably or if the uncaching variant
>> is required and if this has too high a penalty. I have found that with
>> syntax-ppss, I do get false positives fairly frequently if I don't first
>> call syntax-pps-flush-cache, which would seem to defeat its benefits
>> over parse-partial-sexp.
>
> font-lock uses syntax-ppss, so if syntax-ppss is wrong, font-lock should
> be wrong as well.
>
>> As the buffer is being edited, potentially changing the syntax at
>> random places, it is difficult to determine when the cache will need
>> to be flushed (though I have a couple of ideas that may strike an
>> acceptable balance).
>
> syntax-ppss is supposed to automatically flush the (relevant part of)
> the cache after any buffer modification.  The only exceptions are when
> the buffer is modified in a context where inhibit-modification-hooks is
> set (e.g. font-lock-syntactic-keywords).

hmm, that is interesting. I was getting a problem where characters were
being incorrectly classified as comments when I ran syntax-ppss if I
didn't also run syntax-ppss-flush-cache before calling syntax-ppss, but
the characters were not being fontified as comments. If font-lock is
using the same mechanism, I would have expected more consistency - must
be something else going on.

>
>>>> As you can see, I'm using font-lock-defaults to test whether font-lock
>>>> is enabled. Is this the best way to go or is there a more
>>>> reliable/better test to use?
>>> Any reason not to use `font-lock-mode'?
>> Only that some people don't like to use font-lock. I wanted the mode's
>> functionality to be independent of font-lock and not force people to use
>> it.
>
> No, I mean to use the variable `font-lock-mode' rather than
> `font-lock-defaults'.

Ah, must have missed that - didn't realise there was a local variable
called font-lock-mode. Much better solution. thanks.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Best way to detect font-lock mode is on?

[Stefan Monnier]

>> syntax-ppss is supposed to automatically flush the (relevant part of)
>> the cache after any buffer modification.  The only exceptions are when
>> the buffer is modified in a context where inhibit-modification-hooks is
>> set (e.g. font-lock-syntactic-keywords).
> hmm, that is interesting. I was getting a problem where characters were
> being incorrectly classified as comments when I ran syntax-ppss if I
> didn't also run syntax-ppss-flush-cache before calling syntax-ppss, but
> the characters were not being fontified as comments. If font-lock is
> using the same mechanism, I would have expected more consistency

Indeed.

> - must be something else going on.

My point exactly.  If you can come up with a recipe that reproduces it,
we can probably help track down the origin of the problem.

> Ah, must have missed that - didn't realise there was a local variable
> called font-lock-mode. Much better solution. thanks.

(Almost) all minor modes have both a function and a variable of the same
name, where the variable stores the state (on/off) of the mode.
Check the Minor mode section in the Elisp manual.


        Stefan

Re: Best way to detect font-lock mode is on?

[Elena]

On Jan 5, 5:50 am, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> > Yes, that is how I plan to do it if font-lock is not enabled. I'm
> > currently experimenting with syntax-ppss and parse-partial-sexp to see
> > if the cached version can be used reliably or if the uncaching variant
> > is required and if this has too high a penalty. I have found that with
> > syntax-ppss, I do get false positives fairly frequently if I don't first
> > call syntax-pps-flush-cache, which would seem to defeat its benefits
> > over parse-partial-sexp.
>
> font-lock uses syntax-ppss, so if syntax-ppss is wrong, font-lock should
> be wrong as well.

syntax-ppss -> Parse-Partial-Sexp State

Isn't syntax-ppss Lisp-specific?

What about text highlighted by font-lock-add-keywords?

Re: Best way to detect font-lock mode is on?

[Stefan Monnier]

>> > Yes, that is how I plan to do it if font-lock is not enabled. I'm
>> > currently experimenting with syntax-ppss and parse-partial-sexp to see
>> > if the cached version can be used reliably or if the uncaching variant
>> > is required and if this has too high a penalty. I have found that with
>> > syntax-ppss, I do get false positives fairly frequently if I don't first
>> > call syntax-pps-flush-cache, which would seem to defeat its benefits
>> > over parse-partial-sexp.
>> font-lock uses syntax-ppss, so if syntax-ppss is wrong, font-lock should
>> be wrong as well.
> syntax-ppss -> Parse-Partial-Sexp State
> Isn't syntax-ppss Lisp-specific?

Yes/no: it includes a rudimentary parser which can't be claimed to
handle anything more than Lisp (even its handling of Lisp is limited),
but it does handle strings and comment of (almost) all languages.

> What about text highlighted by font-lock-add-keywords?

Unrelated: we're talking about strings and comments which are normally
not highlighted (by font-lock) via font-lock-keywords but via
syntax-tables.


        Stefan

Re: Best way to detect font-lock mode is on?

[Ilya Zakharevich]

On 2011-01-03, Tim X <timx@nospam.dev.null> wrote:
>
> Just wanting to know what people would suggest as the best way to detect
> if font-lock mode is enabled. 
>
> I have two functions I use in a mode to determine if the point is
> currently within a comment or a string. If font-lock mode is enabled,
> this is quite a fast operation as I can just test the text property.
> However, if font-lock is not enabled, I need to do some parsing to try
> and determine whether point is on a comment or string. I have defined
> two functions i.e. 
>
> (defun pde-in-comment-p ()
>   "Returns t if point is within a comment, nil otherwise."
>   (if font-lock-defaults
>       (eq (get-text-property (point) 'face) 'font-lock-comment-face)
>     (nth 4 (parse-partial-sexp (point-min) (point)))))
>
> (defun pde-in-string-p ()
>   "Return t if point within a string, nil otherwise."
>   (if font-lock-defaults
>       (eq (get-text-property (point) 'face) 'font-lock-string-face)
>     (nth 3 (parse-partial-sexp (point-min) (point)))))
>
> As you can see, I'm using font-lock-defaults to test whether font-lock
> is enabled.

No matter what is the test, your logic is not enough.  In cperl-mode,
I pepper all such functions with
   (cperl-update-fontification pos)
(sp?) so that lazy-locking is not playing time-sensitive tricks with
your logic.

Hope this helps,
Ilya

Re: Best way to detect font-lock mode is on?

[Stefan Monnier]

> No matter what is the test, your logic is not enough.  In cperl-mode,
> I pepper all such functions with
>    (cperl-update-fontification pos)

Yes, in Emacs-24, the syntactic fontification has been taken out of
font-lock, and syntax-ppss updates it on-demand, just like cperl has
been doing for ages.


        Stefan

Re: Best way to detect font-lock mode is on?

[Tim X]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

> On 2011-01-03, Tim X <timx@nospam.dev.null> wrote:
>>
>> Just wanting to know what people would suggest as the best way to detect
>> if font-lock mode is enabled. 
>>
>> I have two functions I use in a mode to determine if the point is
>> currently within a comment or a string. If font-lock mode is enabled,
>> this is quite a fast operation as I can just test the text property.
>> However, if font-lock is not enabled, I need to do some parsing to try
>> and determine whether point is on a comment or string. I have defined
>> two functions i.e. 
>>
>> (defun pde-in-comment-p ()
>>   "Returns t if point is within a comment, nil otherwise."
>>   (if font-lock-defaults
>>       (eq (get-text-property (point) 'face) 'font-lock-comment-face)
>>     (nth 4 (parse-partial-sexp (point-min) (point)))))
>>
>> (defun pde-in-string-p ()
>>   "Return t if point within a string, nil otherwise."
>>   (if font-lock-defaults
>>       (eq (get-text-property (point) 'face) 'font-lock-string-face)
>>     (nth 3 (parse-partial-sexp (point-min) (point)))))
>>
>> As you can see, I'm using font-lock-defaults to test whether font-lock
>> is enabled.
>
> No matter what is the test, your logic is not enough.  In cperl-mode,
> I pepper all such functions with
>    (cperl-update-fontification pos)
> (sp?) so that lazy-locking is not playing time-sensitive tricks with
> your logic.
>

Thanks. Will have to give it some thought. The functions I showed above
are not used to control font-locking - in fact, I'm using them to
determine indentation information. The mode is derived from another mode
that takescare of the font locking side of things. If I assume that mode
has taken care of the font-lock issues, I expect the above would be
sufficient. 

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Best way to detect font-lock mode is on?

[Ilya Zakharevich]

On 2011-01-13, Tim X <timx@nospam.dev.null> wrote:
>>> As you can see, I'm using font-lock-defaults to test whether font-lock
>>> is enabled.
>>
>> No matter what is the test, your logic is not enough.  In cperl-mode,
>> I pepper all such functions with
>>    (cperl-update-fontification pos)
>> (sp?) so that lazy-locking is not playing time-sensitive tricks with
>> your logic.
>>
>
> Thanks. Will have to give it some thought. The functions I showed above
> are not used to control font-locking - in fact, I'm using them to
> determine indentation information. The mode is derived from another mode
> that takescare of the font locking side of things. If I assume that mode
> has taken care of the font-lock issues, I expect the above would be
> sufficient. 

Irrelevant.

AFAIU, you think that the logic of delegation

  your mode --> some-other-mode --> text-property(font)-ification

is somehow sufficient to free you from caring about time-related
issues.  Wrong.  Given that WHATEVER-ication would usually (or often?)
run in a time-delayed hook can't be ignored.

Hope this helps,
Ilya

Re: Best way to detect font-lock mode is on?

[Tim X]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

> On 2011-01-13, Tim X <timx@nospam.dev.null> wrote:
>>>> As you can see, I'm using font-lock-defaults to test whether font-lock
>>>> is enabled.
>>>
>>> No matter what is the test, your logic is not enough.  In cperl-mode,
>>> I pepper all such functions with
>>>    (cperl-update-fontification pos)
>>> (sp?) so that lazy-locking is not playing time-sensitive tricks with
>>> your logic.
>>>
>>
>> Thanks. Will have to give it some thought. The functions I showed above
>> are not used to control font-locking - in fact, I'm using them to
>> determine indentation information. The mode is derived from another mode
>> that takescare of the font locking side of things. If I assume that mode
>> has taken care of the font-lock issues, I expect the above would be
>> sufficient. 
>
> Irrelevant.
>
> AFAIU, you think that the logic of delegation
>
>   your mode --> some-other-mode --> text-property(font)-ification
>
> is somehow sufficient to free you from caring about time-related
> issues.  Wrong.  Given that WHATEVER-ication would usually (or often?)
> run in a time-delayed hook can't be ignored.
>

I understand that. However, the test is being applied to earlier points
in the file, not to the current text being inserted. Theoretically, I
guess there could be a very small chance of the text not having being
fontified, but in practice, this does not appear to be the case. Timing
could well be an issue if I wanted to use this information on the text
as it is being inserted, but I'm not testing the current text. If it
does turn out to be an issue, then I will just use syntax-ppss. 

Tim



-- 
tcross (at) rapttech dot com dot au

Re: Best way to detect font-lock mode is on?

[Ilya Zakharevich]

On 2011-01-14, Tim X <timx@nospam.dev.null> wrote:
>> AFAIU, you think that the logic of delegation
>>
>>   your mode --> some-other-mode --> text-property(font)-ification
>>
>> is somehow sufficient to free you from caring about time-related
>> issues.  Wrong.  Given that WHATEVER-ication would usually (or often?)
>> run in a time-delayed hook can't be ignored.

> I understand that. However, the test is being applied to earlier points
> in the file, not to the current text being inserted. Theoretically, I
> guess there could be a very small chance of the text not having being
> fontified, but in practice, this does not appear to be the case. Timing
> could well be an issue if I wanted to use this information on the text
> as it is being inserted, but I'm not testing the current text. If it
> does turn out to be an issue, then I will just use syntax-ppss. 

Feel free to use "theoretical arguments" to make your debugging life
miserable at some time in the future.  [Just think about how you would
determine that "it does turn out to be an issue"?]

Yours,
Ilya