Live data from Hacker News

Turning off syntax highlighting

dudzik.co

101–110 of 192 posts

Re: Turning off syntax highlighting

#101
post #63
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.

More advanced tokenizers are able to emit different tokens for those scopes, but not all syntax highlighters differentiate between them. The online Textmate theme editor is a good place to examine what's availabe because many text editors are able to import .tmThemes or use them directly (Sublime, VS Code).

You can see here that the Monokai theme supports about 20 tokens and doesn't differentiate much between scopes: https://tmtheme-editor.herokuapp.com/#!/editor/theme/Monokai

Personally, I prefer highlighters that do something to highlight variables differently, like this variant of Monokai (ie around line 45 for the JS example): https://tmtheme-editor.herokuapp.com/#!/editor/theme/Monokai...

Re: Turning off syntax highlighting

#102
post #90

Syntax 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.

> because nothing there is a language keyword

What editor are you using where the highlighter doesn't identify user-defined types, member functions, namespaces, local variables? Maybe you don't realize it has these capabilities because it's configured to highlight them with the default?

Re: Turning off syntax highlighting

#103

Turning syntax coloring off was the best decision in my career. I have never looked back.

I wouldn't go as far as to say it was my best decision in my career, however it was an important one. I've noticed how I've gone from "click-friendly" GUI's and window managers like Gnome/KDE to Fluxbox, turned syntax highlighting off and at the same time increased my productivity/effectiveness. At first I missed the "fanciness", the new felt boring and pale, however as time passed it made me realize that I'm now focusing on the important things and I'm in control. So yes okay, it's one of my best decisions.

Re: Turning off syntax highlighting

#104
post #2

Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do via git diff / pull request view, which does not have syntax highlighting (other than red/green for removals/additions), and I always strive to make the diff look good for each commit (which means, doing one thing at a time in each commit, and making sure it reads well). Unfortunately, not e…

I prefer doing this with 'git gui'. It's standard and is very simple to use. What is important you can easily select chunks or lines to stage or unstage.

Re: Turning off syntax highlighting

#105
post #93
post #37

Earlier 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...

SmartGit is wonderful - I've used it for years - and it works on Linux, macOS, and Windows.

http://www.syntevo.com/smartgit/

Re: Turning off syntax highlighting

#106
post #93

Earlier quoted context omitted.

Unfortunately, nome of those neat git GUIs work on Linux...

Not true: https://www.gitkraken.com/download

Propietary, requires an account and mergetool is behind a paywall (although this is not as significant). Ouch.

Re: Turning off syntax highlighting

#107

Even better - we should ditch color monitors altogether. You know, to be edgy and different.

My first thought was that if we close our eyes while programming, that will force us to really understand the code we write...

As someone put it, it feels like "broscience".

Re: Turning off syntax highlighting

#108
post #3

I totally agree with this, and use `:syntax off`, but comments really mess with visual clarity. For dimmed comments, I sometimes switch to nofrils. https://www.robertmelton.com/2016/04/10/syntax-highlighting-...

Comments are the most important part of code. They should not be dimmed. If anything, they should be the only thing that is highlighted.

I'm arguing that dimming them makes them easier to see. Code and comments are interspersed, and are each harder to see when they're the same color.

Re: Turning off syntax highlighting

#109
My solution for half a year now, after years of a bajillion themes, it's hard to go back, using a light theme with dark text works to an extent but I code mostly at night so I need a dark theme in general. Just use about 2 shades of grey and one other soft color. https://i.imgur.com/FHALH2G.png -- or search for Phoenix theme

Re: Turning off syntax highlighting

#110
I 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 treatment because they're sufficiently obvious on their own.

The base text colour has a small distinction between keywords (darker) and everything else (lighter).

Sometimes I'll pull in another colour if I'm in something like Python for things like decorators, to create a distinction between code and meta-code.

This takes care of 95% of the visual distinguishing that's useful, and the rest is noise that adds cognitive load to track. As a bonus, because it's common to all languages in which I work, switching is easy because almost every language breaks down nicely between these categories.

Post reply on HN