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 23:10:43 -0400 wrote:

[...]

 > Why prohibit the hooks from the base buffer?  If they're there it's
 > presumably because they're needed.

I thought that foreign chunks should be completely invisible. Your
example disproves the point, indeed. Thanks.

[...]

 > OK, let's say you chunks

 >     chunk 1 in mode A
 >     chunk 2 in mode B
 >     chunk 3 in mode A

 > And let's say that mode A does some clever caching, so it sets up an
 > after-change-functions hook to flush its cache.  Now you go and delete
 > a block of text in chunk 3, mode A is not warned about it and fails to
 > flush its cache which now holds completely broken data about chunk 3.

 > Of course, running the after-change-functions only in the base buffer
 > won't directly help with that.  

If the patch that you propose is ever implemented, local hooks will
still be run in current buffer, right?


Coming back to the original jit-lock problem. I still have no clue how
to fix it without copying the whole initialization part of jit-lock into
polymode.

 > 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 have just tried this in emacs 24.3.1 and font-lock is triggered only
once in indirect buffers. So it's either some corner case that you are
talking about, or font-lock was broken after 24.3.1 and then you "fixed"
it in:

   commit 6e5d23387db48e9bdf116e59bf7ef717c61982a3
   Author: Stefan Monnier <monnier@iro.umontreal.ca>
   Date:   Wed Feb 12 22:29:47 2014 -0500
   
       * lisp/jit-lock.el (jit-lock-mode): Keep it disabled in indirect buffers.


This patch doesn't affect cloning and jit-lock is still active in cloned
indirect buffers.

   
Vitalie