[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Default of jit-lock-stealth-time

From: Eli Zaretskii
Subject: Re: Default of jit-lock-stealth-time
Date: Sat, 03 Mar 2007 17:10:55 +0200

> Cc: address@hidden,  address@hidden
> From: David Kastrup <address@hidden>
> Date: Sat, 03 Mar 2007 14:36:28 +0100
> Apart from "pathological" buffers, paging through a file will deliver
> font locking fast enough to follow the user action

Where ``fast enough'' means what, precisely?

> In contrast, left alone to jit-lock-stealth-time=16, Emacs will
> eventually turn to eating 100% of CPU time (not 1-3%)

How can this happen?  JIT-lock is supposed to fontify at most
jit-lock-chunk-size characters (500 by default), and then refrain from
fontification for at least jit-lock-stealth-nice seconds (0.5 by
default).  How can Emacs take 100% of CPU with these defaults?

Maybe there's a bug?  How much time do you need to wait until Emacs
starts using 100% of CPU on your machine?  I didn't see that, but
maybe I didn't wait long enough.  Also, did you try looking at the
percentage of CPU taken by each application, when the CPU consumption
hits 100%, and if you did, was Emacs indeed consuming 100% or
thereabouts at that time?

> That does not mean that the problematic files will page through
> without noticeable delay when I go through them by hand: they tend to
> react sluggishly to editing.

These delays and sluggishness were what I meant when I talked about
annoyances.  I don't like them.

> I would consider stealth fontification completely useless as long as
> the computer can keep up with the user, which appears to be the case
> for your usage.  In that case, investing the power when it is actually
> needed seems by far the sanest choice.

David, your opinion was heard, loud and clear, several times already.
There's no need to reiterate it.  Doing so just wastes bandwidth.

For my part, I can say that investing a small fraction of CPU power
when none is used is by far wiser than annoying the user with
redisplay delays, if those are noticeable.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]