Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turning off syntax highlighting

dudzik.co

Post reply on HN
Print view View original

31–40 of 192 posts

Re: Turning off syntax highlighting

#31

Post by markbao »

jowiar wrote: post #25

I think a large part of the issue with syntax highlighting is that our "standard" for syntax highlighting is rather dumb. A few thoughts: - Who the hell would write prose by making all the verbs blue, the nouns red, and the adverbs green (or something to that effect). That's what we do for code. Something togglable a-la iA Writer might make sense, though. At the same time, I can sort of understand, though, because we…

I'm not sure I entirely agree with you on your first point. Writing isn't like code in that code is like a complete system of logic. I think having ways to show how that logic is organized, using positioning (whitespace) and coloring of logical operators is a pretty useful addition, whereas highlighting parts of speech (which don't express a logical structure) isn't that useful.

Re: Turning off syntax highlighting

#32

Post by dudzik »

mseepgood wrote: post #26
aratno wrote: post #3

I 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-...

Comments are the most important part of code. They should not be dimmed. If anything, they should be the only thing that is highlighted.

I think that this is dependent on what you are trying to do. If you want to understand what a program does than this is the way to go. If you want to program than you don't necessarily need the comments to be that visible.

Re: Turning off syntax highlighting

#33

Post by vbezhenar »

I don't turn syntax off, but I hate rainbow in my IDE. I usually use bold for keywords, different colors for comments and string literals, underscore for class members (for Java). Basically that's all. I don't need any other highlighting, it's just a noise for me which makes it harder to read the code.

Re: Turning off syntax highlighting

#34

Post by OJFord »

DSMan195276 wrote: post #20
jakub_g wrote: post #2

Slightly 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 agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. 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)…

    > I also consider `git add -A` to be horrible
    > practice. Adding files manually makes you tons more
    > aware
Agreed, but I take it further than that - I always use `git add -p` because it forces me to read through everything, and make everything in the commit deliberate.

Even if you think you just made a slight change to a file or two and definitely want everything, you'd be surprised how often it lets me pick up some aesthetic change, comment change, or dependency version bump that's completely unrelated to the commit message I'm about to write.

Re: Turning off syntax highlighting

#35

Post by eikenberry »

I predict that in a few months the author will turn a toned down version of syntax highlighting back on. All the advantages he stated were the result of disrupting his previous practices. Doing that forces you to reconsider how you do things and end up improving your skills. But they are learned lessons, not some mysterious side affect of less color.

Re: Turning off syntax highlighting

#36

Post by halisaurus »

DSMan195276 wrote: post #20
jakub_g wrote: post #2

Slightly 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 agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. 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)…

I use `git add . -p` which allows me to 1) selectively create my commit, and 2) re-read what I've changed to understand it all better. I agree about wholesale adding, but of course there are exceptions when you already did `git diff` Or something.

Side note: `git status` is not a good means of "knowing what was changed". I see others use it constantly (doing git status -> git add . -> git commit) and it'a sloppy IMO.

Re: Turning off syntax highlighting

#37

Post by iLoch »

DSMan195276 wrote: post #20
jakub_g wrote: post #2

Slightly 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 agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. 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)…

I just don't understand why people use the git CLI. Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity.

Often times I see my coworkers screwing around with git trying to review diffs and commit their changes. One of two things happens: they spend longer than they should doing it, or they do it haphazardly. Sometimes they get it wrong.

Just use a GUI.

I use SourceTree and often find myself committing individual lines or chunks in my files instead of the whole file. I'm confident the average git CLI user doesn't even know this is possible. I can do massively complicated commits with ease because I can see every single line that has changed right in front of me.

I just don't understand the fetishization of source control via CLI. In all likelihood it doesn't make you more productive, and it's probably less accurate unless you really know you way around git.

Re: Turning off syntax highlighting

#38

Post by jmhain »

taeric wrote: post #18
jakub_g wrote: post #2

Slightly 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'm just trying to convince folks to actually write commit messages. :) I don't think anyone is relying on diffs to find bugs. Do they? 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.

I do this, but not mainly to find bugs, though on rare occasions I do. I almost always find something, e.g. stylistic aberrations, overzealous changes from an intellij refactor, debug statements I forgot to remove, part of another change I'd thought I'd stashed but somehow ended up in the commit. It blows my mind that anybody would not read their diffs.

Re: Turning off syntax highlighting

#39

Post by jimktrains2 »

DSMan195276 wrote: post #20
jakub_g wrote: post #2

Slightly 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 agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. 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)…

I always do `git add -p` and `git commit -e -v` so that I know exactly what's in the commit

Re: Turning off syntax highlighting

#40

Post by jstimpfle »

> Conditional syntax highlighting

I think that's the right approach. Different situations afford different tools. In normal usage, reading only in a single color is a real relief to me; but of course it's typically easier to find missing delimiters and such with syntax highlighting.

I've had this shortcut in my vim configuration for a very long time and I use it frequently:

    nmap  :if exists("syntax_on") \| syntax off \| else \| syntax enable \| endif \|
Similarly, there should be actual different flavours of highlighting for different tasks. I have configured a very light highlighting which highlights mostly control flow words (if, while, for, return etc) and maybe strings. It's much better than the colorful default or syntax off for many situations. On other occasions it might be useful to highlight all variable declarations, etc.

I have come to think that it's the same with programming languages: Different languages require you to type different things explicitly. Sometimes that's beneficial but often it hurts. For example, typing a function signature is much more convenient in python (just variable names), but when debugging the explicitness of a more rigid type system often helps finding bugs. Similarly typing "const" or the precise type of integer is really annoying in many situations. It's visually distracting and shifts the focus on alignment or ordering of statements, instead of the problem to be solved. On the other hand, sometimes these things are just important. It would be very nice to have a programming environment where these details can be hidden most of the time and only turned on when really needed.

Post reply on HN