unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: What is the _essential_ difference between lazy-lock and jit-lock?
Date: Fri, 23 Jan 2004 16:29:57 GMT	[thread overview]
Message-ID: <jwvbrouy73a.fsf-monnier+gnu.emacs.help@asado.iro.umontreal.ca> (raw)
In-Reply-To: vetqub.q5.ln@acm.acm

> Surely not - Emacs _HUNG_ with stealth fontification, accepting no keypresses
> (apart from a double C-g), and remained in this state overnight (> 8
> hours).  As I said, I reported this [to bug-gnu-emacs, 24 Oct 2002,
> "jit-lock hangs emacs in certain circumstances"], but I failed to
> follow-up RMS's request for a more precise test-case.  Perhaps I should
> look into this again.  Looking at this bug report again, I also said that
> lazy-lock sometimes hung this way, too.  I'm sure you're right that it's
> the tuning of the stealth fontification that's pertinent here, not the
> difference between lazy- and jit-.

I'm pretty sure I've seen this report (although I can't remember it),
but it sounds like a different problem than just tuning, more like a real
bug, probably a bad-regexp in the font-lock settings of a major-mode (the
potentially exponential behavior of the current regexp-engine is a common
problem).  This was probably compounded by the fact that inhibit-quit is
set during stealth fontification (input is polled instead).

This inhibit-quit issue is probably the one we should fix, although it's
a bit tricky to do right (after all, you don't want to leave wrong
highlighting just because the user happened to hit C-g for some unrelated
reason).  I think we need a "sledge-hammer" variant of C-g.

> The font lock support modes are not documented.  In fact, the reason I
> posted my question last night was because I was considering contributing
> this documentation myself.

That would be extremely welcome.

> Tuning jit-lock is very difficult.  Using customize, even after finding
> the Jit Lock customize group (difficult in itself), there is a
> bewildering collection of options to set.  (I mean here bewildering to
> _me_, and I think I have a better grasp of font lock than typical Emacs
> users.)  It would seem that a detailed understanding of how jit-lock
> works is a prerequisite for setting these options intelligently.  This is
> surely not a good thing.

> Perhaps what is wanted is a command like `(font-lock-tune-font-lock
> 'low-powered-workstation)' by which users could select from amongst
> several pre-defined tunings, somewhat analogous to CC Mode's
> `c-set-style'.

I think the defaults can be improved to make manual tuning rare.  In most
cases, it should be possible for Emacs to automatically detect it's using
too much CPU time and back-off.  The only manual setting that seems
necessary is "save energy" (or is there some way for Emacs to detect
whether the computer is running on battery?) which should boild down to
turning off jit-lock-stealth-time, although it should be done in a more
obvious way (maybe a global `save-energy' variable which lazy-lock and
jit-lock and others can use).

>>> When I was editing a large buffer, continuous background fontification
>>> under jit- gobbled so much CPU power that I sometimes C-z'ed Emacs to
>>> allow (say) a fetchnews run (part of leafnode, a simple Usenet server)
>>> to finish faster.  This is on a 166MHz CPU.

>> C-h v jit-lock-stealth- TAB should list a bunch more variables you can
>> tweak to change the amount of CPU used in the background.

> OK.  Perhaps for me, simply disabling stealth fontification is the right
> thing.

If you're trying to save power, yes.  If not (i.e. if it's to yield the CPU
to other tasks) then you shouldn't need to tune anything (i.e. the defaults
should be improved).


        Stefan

  parent reply	other threads:[~2004-01-23 16:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-22 18:06 What is the _essential_ difference between lazy-lock and jit-lock? Alan Mackenzie
2004-01-22 18:57 ` Stefan Monnier
2004-01-22 23:07   ` Alan Mackenzie
2004-01-22 23:37     ` Stefan Monnier
2004-01-23 10:36       ` Alan Mackenzie
2004-01-23 11:42         ` Eli Zaretskii
2004-01-23 16:29         ` Stefan Monnier [this message]
2004-01-23 19:28           ` Kevin Rodgers
2004-01-26 19:03           ` Alan Mackenzie
2004-01-26 21:46             ` Stefan Monnier
     [not found]         ` <mailman.1214.1074858619.928.help-gnu-emacs@gnu.org>
2004-01-23 22:34           ` Alan Mackenzie
2004-01-24 10:41             ` Eli Zaretskii
     [not found]             ` <mailman.1266.1074941164.928.help-gnu-emacs@gnu.org>
2004-01-26 17:53               ` Alan Mackenzie

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=jwvbrouy73a.fsf-monnier+gnu.emacs.help@asado.iro.umontreal.ca \
    --to=monnier@iro.umontreal.ca \
    /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).