This seems to be an over-reaction to overly highlighted code. I work with Erlang in Emacs, and at first I couldn't believe how much of a Christmas tree my code looked like: every token had its own color, and it was really hard to read. Fortunately, erlang-mode has a setting to reduce the amount of highlighting. I don't think the proper reaction to a code base that has too many colors is to have none at all: trop c'est comme pas assez. I think many would be happy with some limited highlighting, for example comments, strings, and other constructions that can span multiple lines, incorrect escape codes, possibly-misspelled identifiers, etc. I don't really need or care that keywords and integer literals are colored differently.
Turning off syntax highlighting
91–100 of 192 posts
Re: Turning off syntax highlighting
#92No 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 highlighti…
Why stop at imitating that amazing coder's choice not to use syntax coloring? Dress like them, and adopt their tastes in music, political views and sexual orientation too.
Re: Turning off syntax highlighting
#93Earlier 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…
Unfortunately, nome of those neat git GUIs work on Linux...
Re: Turning off syntax highlighting
#94I 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.
Interesting, for me it is the other way around. I use syntax highlighting (but mostly go with Vim's shipped defaults) and like the keyword highlighting the most.
E.g. looking at Python code, it highlights 'def', 'if', 'else', 'elif', 'for', 'while', etc. in orange, function identifiers in cyanish and literals (integer, float, strings) redish (on terminal with blackish background).
If I look at code, it helps me to find the beginning of a function and the parts where logic branches (conditions, loops, etc.) start. Some time ago I wrote code without highlighting and although it is obviously possible I found it harder (i.e. it took me more time) to navigate for my eyes. Maybe just using bold or italic would be enough, though.
However thinking about it, it might be a nice experiment to highlight identifiers with a unique color (or at least highlight all occurrences of an identifier below the cursor - I think Eclipse does something like that).
Re: Turning off syntax highlighting
#95Syntax highlighting only helps with the easy stuff. It doesn't do anything for std::array , max_window_count>{}; or s.lines() .map(|bline| UnicodeSegmentation::graphemes(bline, true) .collect:: >()) .map(|line| wordwrapline(&line, maxline, maxword)) .collect:: >() .join("\n") because nothing there is a language keyword.
A highlighter in Visual Studio is able to distinguish (at least) preprocesor definitions, variables and class names.
Re: Turning off syntax highlighting
#96I 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.
IntelliJ & MATLAB both change highlighting to indicate variable scoping etc, so it's neither unseen nor impossible, just uncommon in simpler editors.
Re: Turning off syntax highlighting
#97Earlier 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...
Not true: https://www.gitkraken.com/download
Re: Turning off syntax highlighting
#98In 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 mu…
> which is only his own code by the way
Yes, working in a team is definitely a different endeavor. If your teammates or organization aren't open to changes to the style guide then I wouldn't recommend turning syntax highlighting off.
Re: Turning off syntax highlighting
#99Even 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.
Re: Turning off syntax highlighting
#100Earlier 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)…
> 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 use `git commit -a` a lot, but only after checking `git status` (or `git diff`), which is probably my most-used git command.
Those two A's have completely different meanings though (add all, commit amend), not sure I understand how it's relevant to the parent?