[Top][All Lists]

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

Re: trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled

From: Stefan Monnier
Subject: Re: trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled in indirect buffers.
Date: Fri, 23 May 2014 09:27:35 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

> Waste of time or not, it has been done: https://github.com/vitoshka/polymode

How 'bout we add it to GNU ELPA?

> Only recently I found time to finish the design, but then discovered
> that jit-lock was removed.  I am piggybacking on jit-lock and its removal
> is a real bad luck.  The last thing I need right now is to re-implement
> jit-lock in indirect buffers.

jit-lock support was broken.  So if you want it back, we need to fix it.
The problem is simple: jit-lock relies on the `fontified' text-property
to decide what needs to be (re)fontified.  And like all text-properties,
this property is shared between the base buffer and the
indirect buffers.

So when jit-lock is triggered it has to refontify in all buffers that
share the same base buffer.  And if font-lock is activated in several
buffers which share the same base buffer, they'll fight over their
shared `face' text-property.

A related issue is that after/before-change-functions are currently only
run in the current-buffer, even though the changes affect all buffers
which share the same base-buffer.

I think the right fix is to change the C code such that
fontification-functions and after/before-change-functions are always
obeyed only in the base buffer.  I.e. when displaying an indirect
buffer, we'd check the fontification-functions of the base buffer and
run jit-lock in that base-buffer.  When making changes in an indirect
buffer, we'd check after/before-change-functions in the base buffer and
run them there.

Do you think you could try to write such a patch?


reply via email to

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