Even better - we should ditch color monitors altogether. You know, to be edgy and different.
Sure, also let's chuck scrollback in our terminals. What's done is in the past, people.
Turning off syntax highlighting
131–140 of 192 posts
Re: Turning off syntax highlighting
#132Not this again "We should remove all color from traffic lights and make people remember which position is what"
Re: Turning off syntax highlighting
#133I 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
#134No 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.
You understand wrong. When that author typed ":syntax off" in Vim, he was actually disabling possibly the best syntax coloring engine there is.
Re: Turning off syntax highlighting
#135Re: Turning off syntax highlighting
#136Earlier 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…
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 c…
Whereas in the CLI, complex operations are difficult but possible; trivial operations are also difficult but possible. :)
Re: Turning off syntax highlighting
#137Earlier 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…
Unfortunately, nome of those neat git GUIs work on Linux...
Re: Turning off syntax highlighting
#138Earlier 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…
git status
...
Yep, those are the things I changed git add -A
git status
Yep... git commit
...editing in VI... :wqMischief managed.
Re: Turning off syntax highlighting
#139I 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…
> Given 100% control over typography, how would you format [code] to maximize readability There was a book on this, whose title I'm blanking on. Anyone remember? Color wasn't an element, since it was an older book focusing on printing on paper.
Re: Turning off syntax highlighting
#140Earlier 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…
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 c…
Maybe it is of limited use for non-emacs users, but imho it's a fantastic way to use git with a perfect balance between making simple things very easy to do and allowing (almost) anything you can do with the CLI while providing excellent visual feedback.