No, no, no.
Turning off syntax highlighting
171–180 of 192 posts
Re: Turning off syntax highlighting
#172I 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…
> Who the hell would write prose by making all the verbs blue, the nouns red, and the adverbs green (or something to that effect). Slightly off topic, but I think doing this could actually be useful for learning languages, especially highly inflected ones (if you extend the color coding to account for gender, case, etc.).
The farm was used to produce produce.
He could lead if he would get the lead out.
A bass was painted on the head of a bass drum.
That that that that boy said is not that that that that boy said.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.
Re: Turning off syntax highlighting
#173Earlier 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…
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…
I usually have a paper and pen at hand, all non-current work goes there — empty circle and todo text. It was my bad habit to patch things immediately at sight. That way I sometimes missed part of context, either of main task, or secondary, depending on complexity of both.
Maybe this step-by-step working scheme was influenced by svn that cannot commit partial changes, but it seems a good practice on its own, especially in total refactoring.
Re: Turning off syntax highlighting
#174I 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.
What I don't understand is that people want to highlight keywords . Bold is a very strong highlight compared to coloring it. However, keywords (if, while, return) can probably be guessed from the indentation alone. There is little need to guide my focus to them even more.
It allows to quickly understand general structure of the code. Indentation helps too, but it's not enough to quickly distinguish between "for" and "if", for example. Or may be I just got used to it.
Re: Turning off syntax highlighting
#175Earlier quoted context omitted.
> 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…
As someone in pretty much the same boat, try SourceTree or the like. I still use Git from the command line, but it really opened my eyes on what Git can do.
Re: Turning off syntax highlighting
#176Earlier 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 recommend using `git commit -p`, which is a shorthand for `git add -p` followed by `git commit`.
Then, `git show` before you do `git push`.
Re: Turning off syntax highlighting
#177Earlier 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…
> 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.
If I do such minor corrections, I usually commit them immediately (via `git add -p` or better `git commit -p`), so they are out of my way.
Re: Turning off syntax highlighting
#178This seems like old-is-new waxing, reaching for some reason the old way is better. > Initially, turning off syntax highlighting felt weird. I couldn’t skip through the source that fast anymore and it became harder to read. It does, that's the point of syntax highlighting. This isn't a good thing(tm). > Even though this appeared to be an impairment I found it to be the strongest argument for making the switch. By forc…
You know that vim can syntax-highlight too, right?
Re: Turning off syntax highlighting
#179I 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.
As pYQAJ6Zm says: they're not invisible, but when I'm looking at code, they're easily ignored, and when I'm looking at comments, they're easily located. Using solarized dark, the background is Base 03 'bright black' (#002833) and the comments are Base02 'black' made a bit lighter (#004f62).
Comments are for holding details: I shouldn't need them to understand code, at least superficially/structurally. But they should be there if I need to drill down on something a bit, and making it so that focusing on that extra detail is easily skipped or applied makes the overall code reading much more fluid.
Re: Turning off syntax highlighting
#180Earlier 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…
git status ... Yep, those are the things I changed git add -A git status Yep... git commit ...editing in VI... :wq Mischief managed.
Yep that's the way to do it. Assume that you want to add all files (which is usually the case) and then just double check before. This is my practice.