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

71–80 of 192 posts

Re: Turning off syntax highlighting

#71

Post by [deleted] »

msarchet wrote: post #56
jakub_g wrote: post #44

Earlier quoted context omitted.

I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, c…

> because you commit a state of the repo that (probably) never existed The state doesn't exist in the repository until the code has been committed - so your statement is a little backwards. Sure the code might never have only had that edit in it, but the repository has no changes until a commit is made.

[deleted]

Re: Turning off syntax highlighting

#72

Post by JadeNB »

iLoch wrote: post #37
DSMan195276 wrote: post #20

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…

> Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity.

Surely the exact comment, with the roles of 'CLI' and 'GUI' switched, could be made without anyone necessarily noticing. The anecdotal evidence of what works, and doesn't work, for you should not, I think, be regarded as any particular evidence of what does work for anyone else, much less what can work for everyone else. (As has already been pointed out, your child posts are full of responses from people with other experience.)

Re: Turning off syntax highlighting

#73

Post by kpil »

Ok, this thing with young developers going into grandfather-mode is starting to get old.

Acknowledge that it's a hipster thing to use vi and fixed gear bikes, and carry on with your life.

Re: Turning off syntax highlighting

#74

Post by geocar »

eikenberry wrote: post #35

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.

That's what robertmeta did[1], but when I turned off syntax highlighting I left it off.

[1]: https://www.robertmelton.com/2016/04/10/syntax-highlighting-...

Re: Turning off syntax highlighting

#75

Post by wallacoloo »

pault wrote: post #45
iLoch wrote: post #37

Earlier quoted context omitted.

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'm confident the average git CLI user doesn't even know this is possible. Your sibling commenters disagree.

In that case, I'll support his conjecture by admitting that I didn't know that was possible. I'm a pretty average git user, if not actually using it slightly more than my peers (many of whom are only switching from subversion to git within the last 3-4 years). But the rate at which I become more proficient in git is extremely slow - you have to go out of your way to learn more about git most of the time. Maybe a GUI would help in that particular aspect, since I could see unknown options and experiment with them.

Re: Turning off syntax highlighting

#76

Post by bluejekyll »

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 much more efficient with it for exactly the reason quoted. To each their own, but having visual cues to help is not a bad thing. I want my job to be easier.

I used to program black on white, then I was converted after jetbrains came out with an excellent dark theme with huge color variants that make code pop even better.

I'll never go back; I want my work and job easy, not made harder.

Re: Turning off syntax highlighting

#77

Post by qznc »

cygned wrote: post #70
qznc wrote: post #63

Earlier quoted context omitted.

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.

Something like this? https://github.com/jaxbot/semantic-highlight.vim

From reading the README, it just cycles through colors. The colors are random, not semantic, so the name seems to be misleading?

Re: Turning off syntax highlighting

#78

Post by Adverblessly »

qznc wrote: post #63
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…

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.

EDIT: Actually, I think I misunderstood what you meant.

What you are describing sounds like regular syntax highlighting to me. This is my current theme: http://imgur.com/a/cQbWL You can see the level of customization available fits with what you described.

And it has really helped many times in the past, preventing all sorts of silly mistakes that could have been hell to debug. Like shadowing a variable :)

Re: Turning off syntax highlighting

#79

Post by OJFord »

jakub_g wrote: post #44
OJFord wrote: post #34

Earlier quoted context omitted.

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

I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, c…

    > and avoid doing more than one thing in the first
    > place (which would make me want to use `git add -p`)
Yep, I still _avoid_ it, but I'm often surprised by something that slips through - e.g. a typo in a comment that I just changed as I read through - but a comment somewhere totally unrelated to the present commit.

Maybe your better at avoiding it than I am, but I find it to be easily done.

Re: Turning off syntax highlighting

#80

Post by DSMan195276 »

jakub_g wrote: post #44
OJFord wrote: post #34

Earlier quoted context omitted.

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

I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, c…

I understand what you're getting at, but unfortunately I just don't write code that way (And I'm not really sure I know tons of people that do). I always end-up making changes or realizing things halfway into working on something. That said I do understand your point, generally what I do is commit 'logical' parts of my work (Generally using `git add -i` to commit individual chunks), and then when I'm done I checkout each commit to test it compiles on its own.

The fact that `git` makes changing your history around easy make this workflow work fairly well without too much extra overhead to achieve a clean history. I don't disagree that doing it right the first time is really the best way to do it, I just don't find that it really works out that way in practice.

Post reply on HN