instead of tracking it on our own.
This does change the observable behavior of highlighting when there are
many unmatched closing delimiters, but the old behavior was
non-contractual and very dependent on the value of jit-lock-chunk-size.
Use cond instead of unless + if to reduce indentation, extract a common
subexpression to a variable, introduce a variable so a multiline function
call can be written in a single line.
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.
Position 5 of the list returned by syntax-ppss is non-nil iff
the character is escaped according to the syntax table. Use it to
remove the special case for Lisps other than Emacs Lisp.
The special case for Emacs Lisp is still there, to catch ?(.
This form, however, is deprecated, confuses many a minor mode and
confuses the emacs-lisp-mode indentation engine, so the special case
will likely go away soon, too.
After this change, rainbow-delimiters--apply-color just calls
rainbow-delimiters--propertize-delimiter, so remove it and rename
the latter to the former.
Important note: this is a *performance optimization only*, yielding
a very easy 10%-15% gain. The code is supposed to work with *both*
dynamic and lexical binding.
The reason we had our own implementation was to avoid
`syntax-begin-function`, which may break the assumption we rely on that
`syntax-ppss` is exactly equivalent to `parse-partial-sexp` from
`point-min`.
Instead of rolling our own, use the standard one, with
`syntax-begin-function` set to nil.
Instead of setting rainbow-delimiters--parse-partial-sexp-cache to nil
when turning on, kill the local binding when turning off. This allows
the GC to collect the old value immediately after the mode is turned off,
instead of when the buffer is killed or the mode is turned on again.
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.
Fanael Linithien