[Top][All Lists]

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

Re: Last steps for pretesting (font-lock-extend-region-function)

From: Stefan Monnier
Subject: Re: Last steps for pretesting (font-lock-extend-region-function)
Date: Tue, 25 Apr 2006 12:05:18 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

> OK.  So FACENAME comes back as nil (which presumably means "don't apply a
> facename property") and the side effect is applying f-l-multiline if the
> buffer line matches the regexp.


>>> What about the run-time overhead of having an extra text property over
>>> the entire buffer?
>> It's not over the entire buffer.
> Load a buffer and wait for it to be jit-locked.  The entire buffer will
> have been scanned and this text property, in effect, set to t or nil on
> every single byte.

Actually the `nil' value is not added, so the property is only added where
it's non-nil.  Hence it's not added to the entire buffer.

>> And I haven't seen any evidence that it's noticeable (especially
>> compared the number of `face' properties or of the `fontified' property
>> added to the whole buffer).
> I'm sure it's not.


> Is it really that important to responsiveness whether the delay happens
> at the redisplay or immediately after the change?  With the after-change
> f-l-e-r-f, only the two boundaries of the region get checked, plus any
> chunk boundaries when this is bigger than 500 bytes.  With the extra
> pattern in f-l-keywords, then entire region gets checked.

But a single command may do thousands of buffer-modifications.

Look at it this way.  Let's define things as follows:
- a single buffer-modification, without your hook, takes time T1
- font-locking, without my font-lock-multiline thingy, takes time T2
- your hook takes times N1*T1
- my font-lock-multiline takes time N2*T2

So your approach can slow down user-visible execution by a fator N1, whereas
mine can slow it down by a factor N2.  So the important question (to me
anyway) is whether N1 is expected to be bigger or smaller than N2.

Note that in all likelyhood T2 is much larger than T1, so it should be
expected that N1 is significantly larger than N2.

> expensive in aggregate - it marks _every_ sequence which must be
> atomically fontified, just in case that sequence might straddle a chunk
> boundary in the future.

No: it's only applied to those atomic elements which do straddle
a line boundary.

>> I'm as close as it gets to a font-lock maintainer.  So from where I
>> stand, you're trying to impose your taste and judgment on me.

> I'm as close as it gets to a CC Mode maintainer at the moment.  What's
> constraining my freedom in that department now?  ;-)

We're talking about font-lock code here.  You're free to do whatever you like
in cc-mode, including adding an advice to font-lock-after-change-function.

>> It has to be in font-lock-default-fontify-buffer since there's no
>> guarantee this is only called from jit-lock-fontify-now.

> No.  It has to be _called_ from font-lock-default-fontify-buffer.

RIght, I meant to say that there's no guarantee
font-lock-default-fontify-buffer will be called from jit-lock-fontify-now,
which is why a call to extend-region-function needs to be in

>> So you're suggesting to add a redundant call to the extend-region hook.
>> Maybe it's simpler but it's ugly (because of the redundance, and because
>> it adds a dependency between jit-lock and font-lock).

> No.  I'm suggesting refactoring the font lock code a little so that each
> path through it calls the extend-region hook exactly once.  Once in the
> jit-lock "branch" and once in the plain font lock "branch".

That's still redundancy (admittedly less so because it's only static
redundancy).  In my book, if you can get away with putting it it at only
1 spot, it's better from a software engineering point of view.

>> At the same time font-lock-after-change-extend-region-function will be
>> moved from font-core to font-lock (where it belongs) and its
>> make-variable-buffer-local call will be removed as well (use
>> make-local-variable manually if you need it).

> Surely not - that variable is essentially buffer local, and it makes no
> sense for it not to be so.  To remove the make-variable-buffer-local call
> could lead to the same problems which have bedevilled paragraph-start and
> paragraph-separate.

It's a variable which should be modified via `add-hook' (which has
a parameter to specify whether it should be applied buffer-locally or not),
not via setq.  So there is need for make-variable-buffer-local.

Especially since it does make sense to add stuff to it globally as well:
Think about someone who wants to re-add the font-lock-extra-lines feature.
Similarly the font-lock-multiline property could be handled by moving the
code from font-lock-default-fontify-region to this hook.


reply via email to

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