The following is more like a comment since
- it solves only to a small part of the problem (
- it is not thoroughly tested (just with one latex-file)
- I do not completely understand why it works (
font-lock-mode is really quite a complicated machinery)
At first the solution for
We replace the text property
defsubst is used in the package instead of
defun we cannot employ
defalias but must modify the functions themselves (as far as I understand it -- please comment if I am wrong in this regard).
The modified functions are:
(defsubst rainbow-delimiters-propertize-delimiter (loc depth)
"Highlight a single delimiter at LOC according to DEPTH.
LOC is the location of the character to add text properties to.
DEPTH is the nested depth at LOC, which determines the face to use.
Sets text properties:
`font-lock-face' to the appropriate delimiter face.
`rear-nonsticky' to prevent color from bleeding into subsequent characters typed by the user."
(let ((delim-face (if (<= depth 0)
;; (when (eq depth -1) (message "Unmatched delimiter at char %s." loc))
(add-text-properties loc (1+ loc)
;; 2015-05-24: Changed font-lock-face to face to enable rainbow after syntax fontification in latex-mode
;; (see http://emacs.stackexchange.com/questions/4260/how-to-get-rainbow-delimiters-rainbow-blocks-to-highlight-in-line-math-in-latex)
(defsubst rainbow-delimiters-unpropertize-delimiter (loc)
"Remove text properties set by rainbow-delimiters mode from char at LOC."
(remove-text-properties loc (1+ loc)
;; 2015-05-24: See corresponding line in `rainbow-delimiters-propertize-delimiter'.
Now the reasoning:
The embedded formulas between the $-delimiters are syntax fontified by font-lock-mode (as already Kirill pointed out). The registration of this fontification looks normal (see variable
font-lock-syntactic-face-function and function
describe-char at the characters of an embedded formula shows that syntactic fontification uses the
face-property instead of the
The following is hypothetical since I do not completely understand the font-lock machinery which is quite complex.
It seems that
face is stronger than
font-lock-face which is dominated by
face of syntactic fontification.
Nevertheless, we have the advantage that syntactic fontification comes first before search (keyword) based fontification which in turn uses jit-lock (see info-pages of
That leads me to the conclusion that the problem is solved if we use
rainbow-delimiters instead of
And here I do not know the full consequences. But, since
rainbow-delimiters also uses
jit-lock directly (and not through
font-lock-mode) we are standing on a shaky floor anyway.
Note, that I had already some contact with
rainbow-delimiters (see https://stackoverflow.com/questions/19800243/highlight-first-mismatching-paren/20022030#20022030) but not with
rainbow-blocks. Because I have only a limited frame of time I chose to concentrate on
rainbow-delimiters. Maybe, you can solve the
rainbow-blocks-problem in a similar way.