search

Fanael / rainbow-delimiters

Emacs rainbow delimiters mode
GNU General Public License v3.0
673 stars 33 forks source link

Incorrect highlighting with ?[ #5

Closed Wilfred closed 9 years ago

Wilfred commented 9 years ago

Related to https://github.com/jlr/rainbow-delimiters/issues/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:

rainbow_delimeters

purcell commented 9 years ago

The old backslash-less escaping style is now explicitly unsupported. See https://github.com/Fanael/rainbow-delimiters/pull/4 for discussion.

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

Wilfred commented 9 years ago

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 https://github.com/jlr/rainbow-delimiters/issues/15!

purcell commented 9 years ago

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 commented 9 years ago

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:

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. 30c6a4c1bc 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.