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

[Vitalie Spinu <spinuvit@gmail.com>]

 >>> Stefan Monnier on Fri, 23 May 2014 09:27:35 -0400 wrote:

 >> Waste of time or not, it has been done: https://github.com/vitoshka/polymode
 > How 'bout we add it to GNU ELPA?

That would be great, but how often can I update it at ELPA? AFAIK elpa
is for "stable" packages and polymode is still pretty far from being
stable. There is still some work to be done - chunk cashing with text
properties, indentation tweaks, poly-web-mode, etc.  MELPA works just
great for quick syncs.

[...]

 > 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.

I think I saw a couple of infloops because of that.

 > 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.

Why exactly after/before-change-functions should work in the base buffer
only?

At least from polymode prospective it would be ideal if
font-lock/change-functions could act *only* on current buffer. In
polymode each mode has its own buffer and font-lock and change-functions
are very different in base and indirect buffers. So, if I am in C++
chunk, font-lock and change-functions better be from and act on current
C++ buffer, not on the base buffer which is typically in fundamental
mode.

I guess for after/before-change-functions this argument applies more
broadly. One might want to have a change-function that acts differently
depending on whether the current buffer is indirect or not. For example
auto complete popup implemented with overlays must act in current buffer
because overlays are not shared.

How about fixing the problem by enforcing the font-lock/change-functions
only in the current buffer? That is, when in indirect buffer, fontify
only indirect buffer, when in the base buffer, fontify only the base
buffer. I thought this was how it worked before.

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

I am not familiar with emacs C internals but I can definitely look into
that; great opportunity to learn. It won't be very quick, though.

  Vitalie