> 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. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
