Re: jit-lock refontifies too much

[martin rudalics <rudalics@gmx.at>]

 > This is ugly: problems specific to emacs-lisp-mode should not be fixed in
 > jit-lock but in lisp-mode.el.  I'm not sure how to fix it, tho.  Maybe you
 > could (in lisp-font-lock-syntactic-face-function) place
 > a jit-lock-defer-multiline property.
 >

It's ugly.  I'll defvar a jit-lock-context-refontify-function and set
that locally in lisp-mode.

 >
 >>+		(if (or (and (memq major-mode '(emacs-lisp-mode lisp-mode))
 >>+			     (or (= (nth 0 ppss) 1)
 >>+				 (= (nth 0 jit-lock-context-ppss) 1)))
 >
 >
 > Here I'd just compare (not (equal (nth 0 ppss) (nth 0 jit-lock-context-ppss))).

That would be wrong - I must refontify when both values equal 1 - else I
wouldn't handle changing

(defvar foo 1 0
   "bar")

to

(defvar foo 10
   "bar")

 >
 > It's not trivial to convince oneself that your code is correct.  I'd rather
 > you arrange somehow to leave as much of the code unchanged.  Among other
 > things, jit-lock-context-unfontify-pos should be set unconditionally in
 > jit-lock-after-change, as before.  Only if your optimization applies, then
 > you should reset jit-lock-context-unfontify-pos.  Basically make it obvious
 > that as long as your optimization does not succeed, the behavior is
 > unchanged.

You're right.  I'll try to follow that advice.

 > The code that does (when (marker-buffer jit-lock-context-start)
 > ...) above is the kind of "oops let's fix things back" kind of thing I'd
 > rather not see.
 >

That code is needed if someone has set `jit-lock-context-time' to a
large value, changes something in buffer A, switches to buffer B, and
changes something in buffer B _before_ jit-lock-context-fontify is able
to handle the modification in buffer A.  In that case, I can't apply my
optimization in buffer A but have to set jit-lock-context-unfontify-pos
to jit-lock-context-start.  If I implement your proposal and retain the
assignment in after-change-functions I shan't need that.