Live data from Hacker News

Turning off syntax highlighting

dudzik.co

151–160 of 192 posts

Re: Turning off syntax highlighting

#151

In the first few sentences he expressly states why you want highlighting: > I couldn’t skip through the source that fast anymore and it became harder to read Which, yes all the modifications to style (which is only his own code by the way) helped factor out. But I bet he'd be even better now with highlighting that he's made these additional changes to his style. I worked for years without syntax highlighting. I am mu…

This was my thought - he's altered his style to be more readable without syntax highlighting, which is all well and good for him, but doesn't necessarily translate to it being more readable with syntax highlighting, and so is not necessarily a grand thing for his teammates who still use it.

Re: Turning off syntax highlighting

#152
post #69
post #7

No thanks. The last time I could bare not using syntax highlighting I was still on MS-DOS. Since Turbo Pascal 7 (released in 1992), syntax highlighting is a must have on my programming environment. But I understand when we are talking about vim, people prefer an hardcore experience.

I first learned C on VMS. When I could use Turbo C on my own computer in the 1990s, syntax highlighting just came along for the ride. I learned vi from Watcom. I used vim. I wrote in perl, and PHP. I also learned Emacs. I wrote in Common Lisp. Syntax highlighting just stayed on. And then I saw someone do something I had never seen before, and I wasn't sure how to do, and I noticed they weren't using syntax highlighti…

Did you have any thoughts of your own about the before/after experience? Or did you simply imitate them on the basis of learning an unrelated trick?

Re: Turning off syntax highlighting

#153

I have 2.5 major distinctions made in my syntax highlighting, and it's common to almost all languages for me: Comments are a shade that's near the background: I can read them if I focus on them, but otherwise they're not present when I'm reading code Strings are a colourful colour, because the next visual distinction I want is between what's an operation or name, and what's data or literal. Numbers don't get this tre…

If making comments invisible is at all helpful, they’re being seriously misused. Comments are supposed to explain what’s going on, and thus make things easier. Hiding them should be very counter-productive.

Re: Turning off syntax highlighting

#154
post #63
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…

Yes, nice idea. For example, it might be helpful to have different colors for local variables, global variables and fields. If you accidentally shadow a variable, you might notice this way. Likewise, highlight macros in C and make them different to variables/functions.

There is a lot of things we can do with highlighting, but that is not one that we should. An online linting tool should tell you that a variable is shadowing another (and I personally believe that it should not be possible at all). If you make a syntax highlighter that can color differently based on scope, you're only one stop away from a tool that can warn you about shadowing anyway.

Re: Turning off syntax highlighting

#155
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 amazed someone wouldn't read their diffs, just for their own sanity. It's a great summary to remind yourself what you just did to resolve an issue. And what if your cat just walked over your keyboard while you weren't looking? Your diff will tell you this. Silly but meaningful example.

Re: Turning off syntax highlighting

#156
post #14

syntax off, proportional width, ( https://twitter.com/rob_pike/status/567476552187641856 ), all code right aligned, ZWS for tabs

- Hey guys we wrote gofmt so all code looks the same.

- Great! Now we can finally get things done and stop bikeshedding!

- Now about that syntax highlighting of yours...

Re: Turning off syntax highlighting

#157
post #37

Earlier quoted context omitted.

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 Sour…

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

That's fine, but on the other hand, a typical GUI limits both your capabilities and your productivity.

About the only interface I prefer over git CLI is magit in Emacs. It's unlike your typical GUI, because you don't have to click at anything (keyboard-operated), and it exposes like 99% of git inside a well-thought-out text-based UI that adds just the right amount of interaction and editor integration. Using magit is incredibly efficient, much faster than even using CLI git.

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

If you don't know your way around git, chances are you're going to seriously screw things up via GUI and you'll have no idea what happened or how to fix it. Starting from CLI is a good way to actually learn the tool, which I believe is crucial regardless of what interface you'll eventually be using.

Re: Turning off syntax highlighting

#158
Not sure about all the benefits and whatnot but I've learned to like 'syntax almost off' better. I do want to differentiate between comments though. And vim adds some of it's own colors to stuff like the linenumbers that I dislike.

So I use this. https://github.com/Kareeeeem/vim-walou

There's more stuff like it but I wanted to pick my own gray values and dislike pure white on pure black.

Re: Turning off syntax highlighting

#159
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 always use `git commit -v` (with alias).

You get the diff in the editor when you write commit message.

Re: Turning off syntax highlighting

#160
post #152
post #69

Earlier quoted context omitted.

I first learned C on VMS. When I could use Turbo C on my own computer in the 1990s, syntax highlighting just came along for the ride. I learned vi from Watcom. I used vim. I wrote in perl, and PHP. I also learned Emacs. I wrote in Common Lisp. Syntax highlighting just stayed on. And then I saw someone do something I had never seen before, and I wasn't sure how to do, and I noticed they weren't using syntax highlighti…

Did you have any thoughts of your own about the before/after experience? Or did you simply imitate them on the basis of learning an unrelated trick?

Yes. Maybe. I don't think I was thinking about it that way. I think it was more like "look at how readable this is[1]", and when I opened it on my own computer all the bright colours were suddenly very distracting so I turned it off.

I would sometimes use ed to make changes to programs since I can see what I was working on before I needed to make a change, so I don't think it was doing anything for me, but at the same time I don't think I ever thought about syntax highlighting until I tried to work with dense code.

I do try consciously to improve myself, but nobody knows how they program and how to get better. The only strategy that has worked reliably: If I see someone do something I cannot do I try their methods until it makes sense in my own mind.

I've tried to write about this previously[2], but most programmers are hostile when seeing someone do something they can't do, rather than just trying it, they make up all sorts of reasons why they don't need to --"it's unreadable"[3] is extremely common, but questions abou[4] is a new one on me.

As it stands: I don't understand syntax highlighting. I'm pretty sure that syntax highlighting doesn't do anything for me in the best case. Maybe. But is it bad? Is turning it off necessary to being a better programmer? I got better when I turned it off, but it really might be a coincidence. I don't know.

[1]: http://kparc.com/b/a.c but not exactly.

[2]: https://news.ycombinator.com/item?id=8476294

[3]: https://news.ycombinator.com/item?id=8477064

[4]: https://news.ycombinator.com/item?id=12887021

Post reply on HN