Interference with Org-mode headings

[Whil-]

Using delimiters in org-mode headings and at the same time having rainbow-delimiters activated causes the font to change on the heading.

Just a minor bug, but anyways =)

[jlr]

I never tracked down what was going on with org-mode+rainbow-delimiters. It didn't seem to do anything (no highlighting at all) when I turned on rainbow-delimiters in org mode, so it's good to know what you saw.

My first guess is that org-mode might be using a jit-lock-fn on its own that somehow gets interfered with by this mode. I know there isn't any font changes (just color changes) in rainbow-delimiters.el, so the fact it causes the font to change is an interesting clue.

I like org-mode a lot so at some point I'll try to track down what's going on here. Thanks for the info.

[Whil-]

A bit of carelessness with words from me above. The font does not change, only the color. And the color changes for the whole headline.

That might make more sense to you =)

[coldnew]

Here's the error in Message after using delimiters in org-mode Error during redisplay: (error "Before first headline at position 1 in buffer MY-ORG_FILE.org)

[jlr]

Thank you for the information. I have been taking something of a short sabattical and shall resolve all open bug reports when back.

I'm not seeing how to set "Vacation Mode" on github from my iPhone, but that's alright.

If you discover anything further feel free to report - I will continue maintaining and improving this mode.

Thanks, Jeremy Rayman

[coldnew]

I have been test rainbow-delimiters these days, now it works on my emacs and org-mode (emacs24-bzr) without the error message :)

Thank you, Yen-Chin, Lee

[Fanael]

The reason seems to be that rainbow-delimiters assumes that, outside of strings and comments, delimiters don't have a font-locking already or if they do, the font-locking spans only one character, the delimiter itself.

In org-mode headings, or in diff-mode, or in any other mode where delimiters may be part of a font-locked piece of text that is not a comment or a string according to the syntax table, that's not the case.

There is no easy way to handle this situation, I'm afraid. I tried to retrieve the existing text properties and add, instead of replacing, the face used, but the results were iffy. In case anybody is interested, here's the diff:

--- a/rainbow-delimiters.el
+++ b/rainbow-delimiters.el
@@ -390,11 +390,15 @@ Sets text properties:
   (with-silent-modifications
     (let ((delim-face (if (<= depth 0)
                           'rainbow-delimiters-unmatched-face
-                        (rainbow-delimiters-depth-face depth))))
+                        (rainbow-delimiters-depth-face depth)))
+          (existing-face (memq 'face (text-properties-at loc))))
       ;; (when (eq depth -1) (message "Unmatched delimiter at char %s." loc))
+      (if existing-face
+          (add-text-properties loc (1+ loc)
+                               `(face ,(list delim-face (cadr existing-face))))
       (add-text-properties loc (1+ loc)
                            `(font-lock-face ,delim-face
-                             rear-nonsticky t)))))
+                             rear-nonsticky t))))))

@jlr: Are we fine with not fontifying the delimiters in this case? This at least won't break and is better that what we have now.