Mistake in matching inside other blocks

[mmahmoudian]

Before anything, I would like to thank you for this nice package, it has saved me a lot of time. Kudos!

I tried to search in issues but I failed to find a similar one. I'm new to Emacs, so I might not have the right lingo and that might have also affected my search. Therefore, I apologize if this is a duplicate.

The issue

I realized that my org todo list is misbehaving for coloring checkboxes, and I managed to narrow it down to this package. I also managed to reproduce it in a clean file:

Here is the text for you to test:

this is some sort of org file  
  
- [ ] a healthy checkbox  
- [X] a healthy checked checkbox  
here we have a parenthesis ( and some ~variable >= 1~ and some more =code here=)  
- [ ] a badly marked checkbox  
- [X] a badly checked checkbox  
  
  This is not resolved with extra )))))))))   

Of course when I toggle the mode via M-x rainbow-delimiters-mode, the issue disappears:

Potential solution

I think it is best to parse the code blocks independently. In other words, parse whatever inside ~ or = in org modes independently, so that for example in case of this example of mine, the > does not leak outside the scope of ~.

---

Again, sorry that I don't have the correct lingo to convey what I have in mind. Emacs has a learning curve that one should go through 😅

[Fanael]

This is a problem with org-mode setting syntactical properties of text incorrectly: since it doesn't require > or ( to be paired with its corresponding opening/closing character, it should not mark them as pairable delimiters in its syntax table, except maybe in contexts where they are paired, by marking those particular uses with appropriate text properties.

This doesn't only affect rainbow-delimiters, but also potentially any other package that relies on the Emacs syntax engine, depending on how tolerant of incorrect syntax it is.

To quote myself from #64 (comment):

Rainbow-delimiters is quite intentionally simply following what the Emacs syntax engine tells it — the same syntax engine that's used by {backward,forward}-sexp and show-paren-mode and everything that calls syntax-ppss and so on — both for simplicity reasons and consistency with the rest of the ecosystem. Changing that would require significant effort that's very similar to #1: not impossible, but very difficult to ensure correctness of, because there are approximately seventy five billion edge cases to consider.