Make rainbow-identifiers not colorize special operators and macros, so they
always visually stand out. Rationale behind this change is that special
operators and macros in Lisp may be considered "syntax" elements, so it makes
sense to have them visually distinguished at all times.
This reverts commit 29c78ce841 and all other fixes
that have been made afterwards.
The motivation is that use-package is seen by many as a replacement for
`require`. Is use-package always defer the loading of packages then is breaks
this use case, this does not respect POLA so even if it was making Spacemacs
loading faster (up to 3s faster on some startup on my machine) we just cannot
use it, it would be irresponsible. Spacemacs should be easy to use, loading
performance will come with time but it is not a priority.
Problem:
The current rainbow-mode screenshot, is from an older version. It shows white
text on light colors. This makes it hard to read the color codes. The old
screenshot hides the fact that issue has been solved.
Solution:
This updates the screenshot, to show it's current behaviour. Where the text
color is either white or black, depending on if the luminance is greater than
0.5 of 1.0.
Most people won't take the time to write their own per-theme colors,
so having high-quality defaults matters more than anything else.
These defaults are carefully balanced statistical averages of all colors
suitable for both light and dark themes, and perfected to work for 90% of
all themes.
It's the BEST out-of-the-box experience we can offer without forcing
all users to write their own individual per-theme optimizations
for ALL of their themes...
It isn't enough to just update the variables! We must also refresh the "font
locking" (syntax highlighting) in all buffers that have rainbow-identifiers-mode
currently active, so that they instantly re-paint with their per-theme values.
Otherwise we get stuck with an ugly mishmash of old colors and a new theme.
This change loops through all buffers and marks matching ones for re-painting,
starting with the current buffer first so that the user sees quick results!
Added support for 9 new themes, and updated the defaults
for some old definitions to much more closely match the "spirit"
of each theme's individual intended brightness
and saturation level.
Now reverts lightness and saturation to the user's fallback defaults.
A suggested future improvement: Revert to whatever would be used
for the current theme, so that it is a true "reset". Such a change
would require decoupling the sat&light code in "colors//tweak-theme-colors".
You have to replace in your dotfile the layer variable
colors-enable-rainbow-identifiers t
by
colors-colorize-identifiers 'all
color-colorize-identifiers can take 3 values:
- variables -> colorize only variables via color-identifiers mode
- all -> colorize all identifiers
- nil -> no colorisation
New key bindings:
SPC t C a -> colorize all
SPC t C C-a -> colorize all globally
SPC t C v -> colorize variables
SPC t C C-v -> colorize variables globally
Per syl20bnr's comment on PR 6192, the package should always be
installed with the colors layer, but only hooked into prog-mode when the
variable is active. Renamed the variable
colors-enable-rainbow-identifiers-by-default to clarify this, and
modified the documentation.
