Turning off syntax highlighting
11–20 of 192 posts
Re: Turning off syntax highlighting
#12It looks like this: http://david.rothlis.net/code_presentation/distracting_synta...
Re: Turning off syntax highlighting
#13Re: Turning off syntax highlighting
#14Re: Turning off syntax highlighting
#15I totally agree with this, and use `:syntax off`, but comments really mess with visual clarity. For dimmed comments, I sometimes switch to nofrils. https://www.robertmelton.com/2016/04/10/syntax-highlighting-...
Great addition. For me this is a use case for conditional highlighting. What I do in my code additionally is to avoid block comments. So you can differentiate them better from your code.
Re: Turning off syntax highlighting
#16Not this again "We should remove all color from traffic lights and make people remember which position is what"
I have gone for a more reserved theme in my editor lately. Currently on solarized again, but probably going back to zenburn soon.
Re: Turning off syntax highlighting
#17Re: Turning off syntax highlighting
#18Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do via git diff / pull request view, which does not have syntax highlighting (other than red/green for removals/additions), and I always strive to make the diff look good for each commit (which means, doing one thing at a time in each commit, and making sure it reads well). Unfortunately, not e…
Similarly, before doing something complicated at work, please talk about it with a coworker first. Last thing I want is to try to decipher a complicated piece of code without a good motivator as to why I'm doing so. Advanced warning is a great motivator.
Re: Turning off syntax highlighting
#19Re: Turning off syntax highlighting
#20Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do via git diff / pull request view, which does not have syntax highlighting (other than red/green for removals/additions), and I always strive to make the diff look good for each commit (which means, doing one thing at a time in each commit, and making sure it reads well). Unfortunately, not e…
I also recommend people to look at the Linux kernel git history for good examples of how to use git well. Even if you have no knowledge of kernel code (and most people don't) it's still extremely clear how each commit makes a single change and is fairly easy to review. Now, the Linux kernel has the luxury of being able to demand people fix their commits, but that's not to say you shouldn't strive to reach similar states in your commits.