> If you change the default to 0, would you please modify C mode
> to set it to 1?
I don't know where it's needed and neither do I know what's the correct
place to put such a thing in CC-mode.
Alan or Martin?
Who does it is not crucial, but I don't want it to be overlooked.
Wo
> I suggest the patch below, which also sets the default value to 0: except
> for some special modes which rely on font-lock-lines-before (and which
> should thus set it explicitly to an appropriate value), setting it to
> something more than 0 will just waste CPU.
> If you change
>> Would that be bad?
> It would slow down editing long lines. jit-lock is supposed to make
> editing faster.
> That would be bad if the slowdown is substantial. But we need
> to see if it is substantial in order to see if it is bad.
It's probably insignificant, and it's only for those
> The default setting of font-lock-lines-before makes it a nop (as it
> should). Major modes which rely on it should set it to the
> appropriate value.
You should modify the corresponding entry in the Elisp manual too.
___
Emacs-devel mailing list
E
> Would that be bad?
It would slow down editing long lines. jit-lock is supposed to make
editing faster.
That would be bad if the slowdown is substantial. But we need
to see if it is substantial in order to see if it is bad.
___
Emacs-d
I suggest the patch below, which also sets the default value to 0: except
for some special modes which rely on font-lock-lines-before (and which
should thus set it explicitly to an appropriate value), setting it to
something more than 0 will just waste CPU.
If you change the defaul
> In `font-lock-default-fontify-region', immediately before the comment
>;; check to see if we should expand the beg/end area for
>;; proper multiline matches
> insert either
>(setq beg (line-beginning-position (1- font-lock-lines-before)))
Oh, I see we viole
>>> Suppose not: Wouldn't that mean `font-lock-lines-before' is useless?
>> Not at all.
> Then you mean that `font-lock-lines-before' is useless with jit-lock?
fumbling about...
Hmm now I see what you mean. I simply assumed that the code for
font-lock-lines-before had been added at the s
>>Suppose not: Wouldn't that mean `font-lock-lines-before' is useless?
>
>
> Not at all.
Then you mean that `font-lock-lines-before' is useless with jit-lock?
> ... font-lock-lines-before has not been introduced to force
> refontification of the previous lines but because the N previous lines ar
> Because this means that every time I insert one character, redisplay
> would refontify `font-lock-lines-before' in addition to the current
> line.
>
> Would that be bad?
It would slow down editing long lines. jit-lock is supposed to make
editing faster.
>
> Whether and when
Because this means that every time I insert one character, redisplay
would refontify `font-lock-lines-before' in addition to the current
line.
That might be somewhat slower--but how much? Would it even be
noticeable?
jit-lock's after-change hook would only reset the
fontifi
>>> The customizable variable `font-lock-lines-before' is not honored by
>>> jit-lock mode.
>>
>> I know what that means in therms of what the code does, but I'm wondering in
>> which circumstance it makes a visible difference to the end user.
>> Do you have a test case?
> Suppose not: Wouldn't t
Because this means that every time I insert one character, redisplay
would refontify `font-lock-lines-before' in addition to the current
line.
Would that be bad?
Whether and when these lines are refontified
would be _also_ decided by the redisplay engine. And the latter doe
Stefan Monnier wrote:
>>The customizable variable `font-lock-lines-before' is not honored by
>>jit-lock mode.
>
>
> I know what that means in therms of what the code does, but I'm wondering in
> which circumstance it makes a visible difference to the end user.
> Do you have a test case?
>
>
Suppo
> (2) Modify `jit-lock-after-change' appropriately by, for example,
inserting
>
>(forward-line (- font-lock-lines-before))
>
> before
>
>(setq start (line-beginning-position))
>
> That seems like the right fix. Why do you think it isn't?
>
>
Because this means that every
> The customizable variable `font-lock-lines-before' is not honored by
> jit-lock mode.
I know what that means in therms of what the code does, but I'm wondering in
which circumstance it makes a visible difference to the end user.
Do you have a test case?
Stefan
___
(2) Modify `jit-lock-after-change' appropriately by, for example, inserting
(forward-line (- font-lock-lines-before))
before
(setq start (line-beginning-position))
That seems like the right fix. Why do you think it isn't?
_
17 matches
Mail list logo
