Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> >> No, indeed, but they're not activated unless the user asks for
>> >> it explicitly.
>> > I don't see how this is relevant.
>> It's relevant because most optional features are turned off.
> Don't we care about optional features anymore, if, when turned on,
> they cause trouble?

jit-lock-stealth is a performance tradeoff, burning more CPU cycles in
the hope of sometimes providing better interactive behavior.

So "keeping Emacs running when it's apparently idle" is not "trouble".

> Don't we want users to be able to turn those optional features on
> without suffering adverse consequences that we can prevent?

I don't think we can prevent them for jit-lock-stealth.
We could try and detect when there's nothing more to font-lock and
disable the timer at that point.  But it's very far form the top of the
priority.

>> > Are we going to tell users not to enable features if they want Emacs
>> > to be friendly to the batteries?  That's not going to happen.
>> jit-lock-stealth is pretty clearly battery unfriendly.  It's in its nature.
> Any program, when it works and burns CPU cycles, is battery
> unfriendly.

jit-lock-stealth does "eager fontification", which implies doing
unnecessary work.  It's a form of speculation.  So it's not just like
"any program".

> The issue we are discussing here is whether it would be a
> good idea to turn such features off under some conditions.

Well, we already turn it off in all circumstances except those where the
user explicitly requests to turn it on, so I thiunk we cover the 99% of
the needs in this area.

>> Yes, we did try to make jit-lock-stealth work acceptably, but after many
>> attempts, we chose to turn it off instead because there's always some
>> situation where it consumes a lot more CPU than what you'd want.
> Not here, it doesn't.

You're just lucky not to hit the problematic cases.


        Stefan