Fanael/rainbow-delimiters — pull request #4 by Fanael (2014-11-05 19:02:18+00:00)
Title: Remove the Emacs Lisp specific escaping test.

In fact, nuke the infrastructure altogether.

Parens as characters without a backslash are nasty and they really should never be used:
- This syntax is discouraged by the GNU Emacs Lisp Reference Manual.
- They confuse many a minor mode, such as `show-paren-mode`.
- The way we currently handle them partially solves the problem, but is a hack made of eldritch magic, implemented by gluing special cases together hoping they'll work...
- ...but it doesn't really work, and it's pretty easy to get mishighlighted delimiters anyway.
- They confuse the Emacs Lisp indentation engine. Really.
- It's the major mode's job to set the `syntax-table` properties on individual characters.

Because of these reasons, it's just easier to drop this misfeature and rely on people to start using `?\(` instead.

And because the whole point of `rainbow-delimiters-escaped-char-predicate-list` is to allow for this, nuke it too. It was never *really* a documented part of the API.

---

@purcell (and others who want this test still there): I'm sorry. I understand that you want it. But the current hack doesn't really work. Try deleting the backslash in this code:
```emacs-lisp
(lorem '(?\[ ipsum))

(defun lorem (ipsum)
(dolor)
(sit amet))
```
The `)` closing the list will be mismatched, and everything below and including the `defun` will have wrong depth.

If you want to have a *truly working* handling of unbackslashed parens as characters, you should probably try and contribute to the `EVIL-ignore-blacklisted-delims-altogether` branch. The approach used there has at least *some* chance of getting this right, for some values of "right".

Or, convince me that the broken mess used by rainbow-delimiters right now is better than a similarly broken non-mess. To be frank, I suggest you invest your time into making #1 mergable instead of trying to convince me, as it's much easier.