Od tego czasu bardziej przypomina komentarz
- rozwiązuje tylko niewielką część problemu (
rainbow-delimiters-mode
)
- nie jest dokładnie testowany (tylko z jednym plikiem lateksowym)
- Nie do końca rozumiem, dlaczego to działa (
font-lock-mode
to naprawdę dość skomplikowana maszyneria)
Na początku rozwiązanie dla rainbow-delimiters-mode
:
Zastępujemy właściwość text font-lock-face
przez face
in rainbow-delimiters-propertize-delimiter
i rainbow-delimiters-unpropertize-delimiter
. Ponieważ defsubst
jest używany w pakiecie, zamiast tego defun
nie możemy zastosować, defalias
ale musimy zmodyfikować same funkcje (o ile rozumiem - proszę o komentarz, jeśli się mylę pod tym względem).
Zmodyfikowane funkcje to:
(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."
(with-silent-modifications
(let ((delim-face (if (<= depth 0)
'rainbow-delimiters-unmatched-face
(rainbow-delimiters-depth-face depth))))
;; (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)
`(face ,delim-face
rear-nonsticky t)))))
(defsubst rainbow-delimiters-unpropertize-delimiter (loc)
"Remove text properties set by rainbow-delimiters mode from char at LOC."
(with-silent-modifications
(remove-text-properties loc (1+ loc)
;; 2015-05-24: See corresponding line in `rainbow-delimiters-propertize-delimiter'.
'(face nil
rear-nonsticky nil))))
Teraz rozumowanie:
Wbudowane formuły między $ -delimiterami są składniane czcionką według trybu blokowania czcionek (jak już wskazał Kirill). Rejestracja tej czcionki wygląda normalnie (patrz zmienna font-lock-syntactic-face-function
i funkcja font-latex-syntactic-face-function
). Ale describe-char
na znakach osadzonej formuły pokazuje, że czcionka składniowa używa face
-property zamiast font-lock-face
-property.
Poniższe jest hipotetyczne, ponieważ nie do końca rozumiem maszynę do blokowania czcionek, która jest dość złożona.
Wydaje się, że face
jest silniejszy niż font-lock-face
. Zastosowania ograniczników tęczy, w font-lock-face
których dominuje face
składniowa czcionka. Niemniej jednak mamy tę zaletę, że czcionkowanie składniowe jest na pierwszym miejscu przed czcionkami opartymi na wyszukiwaniu (słowach kluczowych), które z kolei używają blokady jit (patrz strony informacyjne font-lock-mode
).
Która prowadzi mnie do wniosku, że problem jest rozwiązany, jeśli używamy face
w rainbow-delimiters
zamiast font-lock-face
. I tutaj nie znam pełnych konsekwencji. Ponieważ rainbow-delimiters
jednak używa się jit-lock
bezpośrednio (a nie przez font-lock-mode
), i tak stoimy na chwiejnej podłodze.
Zauważ, że miałem już jakiś kontakt rainbow-delimiters
(patrz /programming/19800243/highlight-first-mismatching-paren/20022030#20022030 ), ale nie z rainbow-blocks
. Ponieważ mam ograniczony czas, na którym postanowiłem się skoncentrować rainbow-delimiters
. Być może możesz rozwiązać rainbow-blocks
problem w podobny sposób.