3 ms·
I have a love-hate relationship with colors in technical environments. When used properly, they are awesome. For example, I have custom syntax rules for assembl
by PhilipRoman 3y ago
I have a love-hate relationship with colors in technical environments. When used properly, they are awesome. For example, I have custom syntax rules for assembly that highlight each register in different colors as well as highlighting instructions based on type. This allows me to visually see dependency chains in disassembler output without having to type a single key.
On the other hand, every single editor from Vim to full blown IDEs has an absolutely braindead idea of what syntax highlighting should be.
Some keywords are useless noise (public, final, const, struct) while other keywords are more important - but usually they are all behind a single syntax rule called "keyword". I want to configure each one individually so I can visually scan code faster. IntelliJ has the right idea with semantic highlighting and I think every editor these days has a rainbow parentheses plugin that helps deciphering long expressions.
Personally, I've fixed this with a few Vim keybinds allowing me to dynamically highlight things that are important at the moment.
For non-interactive use I either use Vim as a pager or pipe to a small script which highlights what I want to see.
- arp242 3y agoIn Vim it's often relatively easy to fix these kind of issues and tweak things to your liking; e.g. "syn clear cStructure" to clear just the highlight for struct, union, and enum keywords in C (and not anything else), "syn clear javaScopeDecl" to disable the scope declarations in Java, etc. Details differ per language; but most syntax files declare fine-grained syntax rule which are then linked to "Keyword" highlight or whatnot later, but there's nothing preventing you from clearing the fine-grained syntax rules (or just defining your own).