So far, we assumed that [] () {} are always the delimiters, and the only
delimiters, we want to highlight. But this is not true. For example, in
Pascal, {} are comment delimiters, and in C++, <> serve as brackets
in template syntax. The respective major modes get this right, we don't,
so rely on them. Code simplification is an added benefit.
Note: currently it's probably buggy and certainly incomplete. For example,
it doesn't respect rainbow-delimiters-highlight-TYPE-p yet.
The PPSS cache can never be inserted into in the middle, so testing whether
to insert into the middle is unnecessary.
rainbow-delimiters-syntax-ppss-run adds all the intermediate results
to the front of the cache, so it always leaves the cache in a state where
the elements are always exactly
rainbow-delimiters-parse-partial-sexp-cache-max-span apart, so there's no
gap bigger than rainbow-delimiters-parse-partial-sexp-cache-max-span to
insert into.
The before change hook always removes all elements until before the point
of the change, leaving no gap either.
The only way for a gap bigger than
rainbow-delimiters-parse-partial-sexp-cache-max-span to arise is the user
changing that variable, but that variable an implementation detail, so
worrying about it changing is like worrying about
(fset #'rainbow-delimiters-syntax-ppss-run #'ignore).
All in all, it serves only to make the code more complicated. So remove it.
Generalized variables are supported in push only since Emacs 24.3,
using primitive operations instead allows the code to work in older
versions, too.
The regression was introduced in 3dfd3fa9b1, fixes#46.
`rainbow-delimiters-mode' may be restored via desktop.el. When this
happens inside an `mmm-mode' buffer, the subregion-specific values of
the syntax table will not be restored, and so
`rainbow-delimiters-syntax-table' can be nil. We handle this case by
skipping propertization if the syntax table is unset.
Closes https://github.com/purcell/emacs.d/issues/209
This allows us to get rid of the with-silent-modifications compatibility
implementation and unpropertizing hacks.
No performance difference unless somebody intentionally misconfigures
Emacs, because font-lock uses jit-lock by default.
Fanael Linithien
Steve Purcell
Sebastian Wiesner