111–120 of 192 posts
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.
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.
Comments are pretty much universally "skimmable" if what you want to get at is the code, and also completely unrelated to actual code (other than describing it), so I think they deserve their own color and that it is helpful. Also, conversely comments in their own color stand out from the code so that if you're looking for descriptions, they are easier to find.
Colors also being useful for constant values (strings and numeric ones alike) because at least I really want something hard coded to stand out. Sometimes it should be hard coded, sometimes it shouldn't, but pretty much always, what the hard coded content _is_, is of interest.
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.
Huh, I thought being "hardcore" about vim meant writing your own syntax highlighting rules. (Which isn't that hard, though vimscript does have some weird quirks.)
I am using Vim dynamically, calling it out of CGIT. For example:
http://www.kylheku.com/cgit/txr/tree/genman.txr
When you access this file, CGIT runs a syntax highlighting shell script where you can hook in multiple approaches (e.g. based on file suffix). I hacked this script to run Vim via Expect, to load the text and save the HTML with :TOHtml.
As you can see, the TXR pattern language and TXR Lisp are nicely separated in the output. The identifiers are colored differently---even in cases when they are the same! Look for a purple (do ...), which is a directive in the TXR pattern language to enclose and evaluate a bunch of Lisp, and green (do ...), which is a totally unrelated construct in TXR Lisp: one of the forms that support explicit partial evaluation.
When I'm coding in TXR, Vim is quite accurate in identifying mistakes like string literals not being closed and parentheses not being balanced and such, or various tokens being malformed and whatnot. It can figure it out in spite of levels of nesting. It significantly reduces such errors.
Stop deflecting blame for being a poor coder
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…
That said, there's a lot you can't do easily or at all from the GUI. Rebases, surgically reverting a series of commits from a bad merge, re-writing branches, blame, bisect, reviewing the history of a single file, checkout of a specific version of a file from a previous revision; there are a lot of things that I can do easily from the CLI that I don't know how to do or don't care to do from a GUI.
Use the right tool for the job. The GUI is great for common tasks and the CLI is great when you need more power.
Earlier quoted context omitted.
Surely this would make people slow down and pay attention or you know just crash more.
Right, but realistically they'd just crash more and then what's been achieved? Some of us get to feel smug about how the daft plebs aren't hard-core enough to navigate without colored traffic lights?
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 like to take advantage of my tooling to make my life easier. Writing good code is difficult enough without imposing additional constraints upon yourself to make it more challenging.