From: Tim X <timx@nospam.dev.null>
To: help-gnu-emacs@gnu.org
Subject: Re: Best way to detect font-lock mode is on?
Date: Wed, 05 Jan 2011 18:55:26 +1100 [thread overview]
Message-ID: <87aajfbx8x.fsf@puma.rapttech.com.au> (raw)
In-Reply-To: jwvzkrfc37z.fsf-monnier+gnu.emacs.help@gnu.org
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
next prev parent reply other threads:[~2011-01-05 7:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-03 2:51 Best way to detect font-lock mode is on? Tim X
2011-01-03 4:59 ` Stefan Monnier
2011-01-03 6:08 ` Tim X
2011-01-05 5:50 ` Stefan Monnier
2011-01-05 7:55 ` Tim X [this message]
2011-01-10 17:39 ` Stefan Monnier
2011-01-05 14:52 ` Elena
2011-01-10 17:40 ` Stefan Monnier
2011-01-12 3:46 ` Ilya Zakharevich
2011-01-12 15:45 ` Stefan Monnier
2011-01-13 1:21 ` Tim X
2011-01-14 1:35 ` Ilya Zakharevich
2011-01-14 6:59 ` Tim X
2011-01-15 7:54 ` Ilya Zakharevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87aajfbx8x.fsf@puma.rapttech.com.au \
--to=timx@nospam.dev.null \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).