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

61–70 of 192 posts

Re: Turning off syntax highlighting

#61

Post by qznc »

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…

Don't you always have commits chains like "add debug printfs" "fix bug" "remove debug printfs"?

Re: Turning off syntax highlighting

#62

Post by dudzik »

codepunker wrote: post #58

Let's not use headlights anymore too... This will force the us to drive more carefully and reduce speed to avoid a potential disaster.

"The removal of road markings is to be celebrated. We are safer without them" - https://www.theguardian.com/commentisfree/2016/feb/04/remova...

Re: Turning off syntax highlighting

#63

Post by qznc »

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.

Re: Turning off syntax highlighting

#64

Post by craigds »

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…

As a counterpoint, every time I've tried a git GUI (I've tried lots), I end up bashing my head against it within a few minutes. They usually make very basic things easy and anything even slightly outside the box basically impossible.

I'm much more productive using a couple of git commands that I can type in a few seconds, rather than hunting for things in menus and dialogs for ages.

> committing individual lines or chunks in my files instead of the whole file

That's really git 101. I'd expect if you haven't learned to do that via the CLI then maybe you gave up too soon and jumped straight to GUI? `git add -p .` is very easy to use.

Re: Turning off syntax highlighting

#65

Post by theptip »

OJFord wrote: post #34
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 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 think this is a good practice; it's always easy to let your attention lapse and skim over a line when you're reading the full diff. `git add -p` is nice in that it explicitly requires you to ack each change.

Re: Turning off syntax highlighting

#66

Post by Freak_NL »

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…

> I can do massively complicated commits with ease because I can see every single line that has changed right in front of me.

You mean `git diff`? I'm sure it comes down to a matter of preference, but claiming that using git from a command line slows you down or limits your capabilities only makes sense if you rarely touch a command line (a bit strange for a developer). Plain old git from the command line is functional and actually quite user friendly. Add your own aliases and some kind of git shell and you can fire off a complicated commit as fast as you can sensibly review your diff — all without lifting a finger from the keyboard.

GUI git tools are nice for visualizing feature branches, but for the basic day-to-day workflow the CLI is much more productive.

Re: Turning off syntax highlighting

#67

Post by k__ »

I have the feeling most of this isn't a direct problem of syntax highlighting.

Most people simply highlight dumb stuff in their code.

For example, comments often have a bad contrast and stuff like brackets, curly braces or parathesis have high contrast.

Re: Turning off syntax highlighting

#68

Post by dwaltrip »

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.

What the commenter means is that one might accidentally select some invalid or non-sensical set of partial changes (that won't compile or run) in an effort to create a logical progression between state A, "no feature", and state B, "feature is complete".

If a bug is found, the invalid state of the intermediate commits might make it harder to isolate the change that caused the bug.

That being said, I generally use "git add -p". I've gotten accustomed to trying to have clean commits. Although, sometimes the changes have enough complexity that breaking them up becomes too painful and I end up with a few messy commits. Such is life.

Re: Turning off syntax highlighting

#69

Post by geocar »

pjmlp wrote: 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 highlighting.

So I turned it off.

Re: Turning off syntax highlighting

#70

Post by cygned »

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.

Something like this?

https://github.com/jaxbot/semantic-highlight.vim

Post reply on HN