How are conflicting faces orders resolved?

Question

(I don't know if the title of this question is correct)

When using several minor modes simultaneously changing 'colors', what determines in which order which modes shows what? For example I'm trying to use both highlight-changes-mode and rainbow-mode: http://julien.danjou.info/projects/emacs-packages

The problem I have is that when I enter a new color in my buffer (say #306090), instead of seeing the background color of the #306090 characters as rainbow-mode would want it to be, I see the background color (of the entire line) as changed (because I'm using highlight-changes-mode, which I like a lot).

My question is kinda a generic one: what determines in which "order" conflicts are resolved here? Does it depend on the loading order of the various modes?

Answer 1

It doesn't depend on the loading order of the modes. It depends on the respective mechanisms the modes use to apply the faces.

rainbow-mode uses font-lock to highlight text, which in turn uses so-called text properties. Text properties are intrinsic properties of string objects, and can belong to string objects that are not part of any buffer. (Text properties thus survive cutting and pasting, for example.)

highlight-changes-mode, in contrast, uses "overlays," which can be thought of as virtual text properties: An overlay is a specification of an interval in a buffer together with a specification of one or more properties that that interval should act as if it had; among the properties that an overlay can specify is a face. Overlay properties are not properties of the strings themselves (and so don't survive cutting and pasting).

If incompatible face attributes are specified by the text property of a buffer substring and an overlay covering that substring, then the overlay takes precedence. (If the face attributes aren't incompatible--as when a text property specifies a foreground color but no background color, and an overlay specifies merely a background color--then they're merged in the fashion you'd expect.)

In general the rules for merging faces are complex, because overlays themselves can specify strings to display at a buffer position, which strings in turn can have their own text properties, and different rules govern such cases; also, certain built-in faces like mouse highlights and mode-line faces are governed by their own rules. If you want to know more, see the info nodes "(elisp) Faces" and "(elisp) Overlays". For the complete story you'll need to look at the source code of the display routine (probably starting with handle_face_prop in xdisp.c and face_at_string_position in xfaces.c).