Incorrect highlighting with ?[

[Wilfred]

Related to jlr/rainbow-delimiters#15 I suspect. Again, it's not recommended elisp style, but it would be nice for rainbow-delimeters to handle this corner case.

(> (julia-strcount before ?[)
   (julia-strcount before ?]))

Highlighting ends up looking like this:

[purcell]

The old backslash-less escaping style is now explicitly unsupported. See #4 for discussion.

In essence, @Fanael has overhauled the entire mode, making it faster, simpler and more maintainable.

[Wilfred]

Ah, I didn't know. As mentioned in that issue, indentation is also completely broken for this code snippet.

I don't think I've written bracket literals without backslashes as paredit doesn't let you (AFAIK). However, I do encounter it fairly commonly. Emacs itself includes this style fairly frequently:

wilfred@vostro-laptop: ~/src/emacs-24.4/lisp
$ ag ' \?}' --nogroup | wc -l
91

As a result, I didn't even find out this style was officially unsupported until jlr/rainbow-delimiters#15!

[purcell]

Yep, I made the same mistake myself in some code I wrote a few years ago, and only discovered it when I found rainbow-delimiters didn't then support that style. It was subsequently worked around, but I think the right approach is to just fix the offending code, including in Emacs itself.

[Fanael]

As mentioned in that issue, indentation is also completely broken for this code snippet.

Yeah. Think about it: not even emacs-lisp-mode gets it right. How is a major-mode-agnostic minor mode supposed to get it right?

As mentioned in #4, the only viable solutions I see are:

• getting Ignore blacklisted delimiters altogether. #1 into a mergable state, or
• somehow getting emacs-lisp-mode to apply appropriate syntax-table properties to the offending characters, either by changing emacs-lisp-mode itself or by implementing a separate minor mode.

Closing as won't fix.

In essence, @Fanael has overhauled the entire mode, making it faster, simpler and more maintainable.

Faster? The rest is spot on, but faster? Probably not. 30c6a4c reduced the performance¹ by quite a lot and all further changes are barely able to recoup that loss.

1. Think about it: re-search-forward used to look for a set of hardcoded characters. That's pretty much a byte scan, so it's blazing fast. Now it has to look for characters whose syntax table descriptors indicate the characters are opening or closing delimiters, and these come from various sources: the syntax table entries, syntax-table properties, syntax-table properties on overlays, plists of category properties and plists of category properties on overlays. That's a lot of things to consider, and I wouldn't be surprised if there are even more possible sources that I'm not aware of.