1. 27
  1.  

  2. 41

    I don’t think syntax highlighting is a sign of weakness or not understanding a language.

    1. 7

      I wonder if someone would see it as a weakness to use proper formatting or to use obviously named variables. It’s just a preference like tabbed spacing or anything else.

      1. 6

        On one hand, humans have color perception for a reason, so not using syntax highlighting is consciously handicapping yourselves.

        On your other hand, the article argues that syntax highlighting distracts you from semantics, so maybe what we should really use is semantic highlighting. But even then you’d still be using colors, so either way.

        1. 14

          What I’ve found is that, especially in Vim, because just about everything is highlighted, it ends up just looking like a big jumble of colours and nothing stands out (it’s also very inconsistent and the syntax files are a mess). And then you’ve got issues like native types being highlighted, while custom types aren’t recognized which is just confusing. I’m a fan of minimal highlighting, and I’ve gradually dialed my personal colour scheme right back to only highlighting comments and ‘TODO:’, ‘NOTE:’ (so they really catch my attention), and a few very specific things like function/method definitions to make it easier to visually scan a file.

          1. 7

            I think colors are best reserved for marking important things. Splashing the code with a rainbow of colors prevents anything from standing out.

            1. 6

              I wrote on this topic; I agree that going without syntax highlighting is making it harder on yourself (e.g., not noticing that the code you are looking at is in a huge comment block or that you used an incorrect escape sequence), but too much highlighting and nothing particularly stands out. I made my own theme where most text is in one color, and I highlight comments, string literals, function definitions and a couple of other constructs. I particularly like the highlighting of function definitions, it helps my to quickly see where one function starts and where another begins.

              I don’t have any particular talents in art, color theory, design, UX, and all that, and I’m sure that a competent theme designer could take only 3-4 colors and create a theme that really highlights the value of syntax highlighting.

              1. 3

                not using syntax highlighting is consciously handicapping yourselves

                While understanding that syntax highlighting, like editor and programming language choice, is highly subjective, I disagree with this statement.

                I personally find that disabling syntax highlighting, and all colors in my terminal, helps me to focus on the actual semantics. I find that I actually read the code more carefully and retain more of the substance than when using highlighting.

                I also find that disabling highlighting is particularly useful for viewing files written in programming languages I’m less familiar with. While yellow may mean parameter in one language, it may mean class declaration in another. Disabling colors completely removes any chance of information bias based solely on a first glance.

                I would love to see any studies you have to support the theory that not using syntax highlighting when reading code is an intentional handicap. I would also love to know in what ways you think it is handicap. Is my understanding of the code compromised? Am I slower and less productive? How do you measure how handicapped I am?

                1. 3

                  I personally find that disabling syntax highlighting, and all colors in my terminal, helps me to focus on the actual semantics. I find that I actually read the code more carefully and retain more of the substance than when using highlighting.

                  “On your other hand, the article argues that syntax highlighting distracts you from semantics, so maybe what we should really use is semantic highlighting.” :P

                  I would love to see any studies you have to support the theory that not using syntax highlighting when reading code is an intentional handicap.

                  Here you go!

                  1. 2

                    “On your other hand, the article argues that syntax highlighting distracts you from semantics, so maybe what we should really use is semantic highlighting.” :P

                    Yes, that’s why my statement was prefaced with “I personally”. I interpreted your use of “on your other hand” (emphasis mine), to mean you were incredulous of that argument. I was adding my own personal experience and preferences to the discussion.

                    I can’t speak to the papers, as I’m reading them now, but I appreciate the sources. You did not, however, answer how I am handicapped. Simply trying to authoritatively state that forgoing highlighting makes me perform at a lesser degree than someone using highlighting is a broad and vague statement.

                    1. 2

                      That’s fair. My position is more philosophical: colors are very information dense for humans, so we should leverage that for parsing code. That doesn’t mean any particular syntax highlighting scheme Is Good, or even that our current position on syntax highlighting Is Good- I think it’s helpful, but there’s a lot of room for improvement.

                      One thing I haven’t really seen, but am really into the idea of, is semantic highlighting. That would be things like “color any function that’s imported somewhere else in the codebase” or “highlight any variable I later mutate.” Those would potentially be a lot more powerful than just coloring keywords and such, but would also be trickier to write a highlighter for, which might be why nobody’s done it yet.

                      Edit: “your other hand” was a typo :/

                      1. 2

                        That’s also fair. I was mostly just wanted to dig into the theory that anyone not using highlighting is intentionally handicapped. I, clearly, disagree there but I definitely accept that feelings around highlighting, like most programming-related meta-things, are highly subjective.

                        While I do not use highlighting, I’m also interested in seeing how tools can improve to help people perform their tasks to the the best of their ability. I’m not opposed to highlighting existing and would love to see improvement made to make highlighting more useful. Semantic highlighting would be very interesting and I would definitely give it a try.

                        I just don’t don’t buy that I’m at a disadvantage by not using normal syntax highlighting.

                      2. 2

                        Neither paper actually says I am at a handicap. What they do say is that syntax highlighting is useful among certain portions of the programming population for quickly identifying certain characteristics about a program. Neither explores whether the users already used syntax highlighting, or the same tools and same colors used in the study, or how the highlighting affects the understanding of a program in someone who normally does not use highlighting,.

                        I believe you are misrepresenting the data in those papers as “not using syntax highlighting is intentionally handicapping yourself” when in fact the first paper says syntax highlighting can be beneficial for identifying certain program constructs (first paper) and the second paper clearly states that “the magnitude of the effect [syntax highlighting has] decreases as programming experience increase”, though it does say it can reduce context switching.

                        So, my question is still, why do you think I’m at a disadvantage and how does this manifest?

                      3. 1

                        Very interesting links, thanks for sharing. When I was debating a similar subject, I was looking for similar documents but could never find any.

                    2. 2

                      On one hand, humans have color perception for a reason, so not using syntax highlighting is consciously handicapping yourselves.

                      I’ve never seen this brought up about IDE’s. That’s a great point. It’s reinforced in many other areas such as UX and marketing materials. Hell, even the milk I buy is always red since many generic, grocery items are categorized by color for instant recognition. It’s proven to be a useful psychological effect in general. So, we should leverage color for categorization in IDE’s. How to best do that is obviously still an open topic but keywords vs functions vs type vs etc have been useful so far.

                      1. 1

                        keywords vs functions vs type vs etc have been useful so far

                        I don’t agree with this at all. I appreciate that people like it, but I bet many orders of magnitude more time have been wasted trying to tell the difference between $accountCount and $accountCⲟunt than between private and personal.

                        Maybe even more when you consider colour fatigue tricking the programmer into thinking there’s no difference between the lines…

                        1. 1

                          Hmm. We could make the keywords all one color with the usesr-supplied identifiers on a given page being different colors. How about that?

                          1. 1

                            Maybe. It certainly sounds more useful than what vim and sublime editor do. There’s some risk though, and it’s unclear how common purposeful variable shadowing is:

                            let accountCount=get(); 
                            do_something(function() {
                              let accountCount=get();
                              ...
                            });
                            

                            The two “accountCount” variables above should be different colours, and while shadowing occurs frequently in my programs, in other programs it might be a bug.

                    3. 2

                      Obligatory quote: http://aiju.de/rant/syntax-highlighting

                      That is what overly highlighted code looks like to me.

                      For me, proper indentation / spacing and code layout is way enough for reading.

                      For writing, highlighting strings reveals to be appreciated to me, but still, in languages such as shell script, you can quote every single word or let it unquoted. Syntax highlighting for strings then become totally pointless.

                      When I use vim, I switch between :syntax off for less rainbow reading and writing and :syntax on when I have a doubt about a string quote in a shell script or such.

                      Proper color theme is also a good compromise.

                      1. 2

                        What I am often looking for with a syntax highlighter is a good linter instead. A syntax highlighter is also a linter that display the result as colours on the text…

                    4. 6

                      But sometimes vim is vi, and sometimes emacs is vi, and sometimes people forget that the Ixians derived their name from the fact that theirs was the ninth planet of their solar system.

                      1. 4

                        The two main reasons I can’t use nvi are lack of ‘expandtab’ (which in languages where the convention is to indent with a certain number of spaces is very annoying), and the lack of a way to set options based on filetype. All I really need is some command that matches on pathnames like:

                        setfor *.rb et ts=2 sw=2
                        

                        Maybe I could achieve something similar with a wrapper script, I’m not sure. But even then, the lack of ‘expandtab’ is a deal breaker for me.

                        1. 2

                          In acme, I use hard tabs for everything and git filters to convert to spaces.

                          It’s not free of quirks. Works well most of the time.

                        2. 4

                          On a tangent, I’ve found that having a lack of deep understandings of vim makes me more capable of doing my day-to-day tasks using just vi because I’m so used to using primitive key bindings.

                          1. 6

                            This is good to make sure your code is available to read on every system, regardless of locale

                            Wasn’t UTF-8 designed so that the text will be available to read on every system, regardless of locale?

                            1. 3

                              No.

                              UTF-8 is just one way to encode the code points of a particular character set.

                              It does absolutely nothing to guarantee that the text can be properly rendered or processed.

                              1. 3

                                With UTF-8 you don’t need to know the source locale that was used to construct the text file. This alone is kind of a big deal, because you just write your stuff in UTF-8 and magically the text file contains all information to be properly read on any other system. Having this in mind, the “does absolutely nothing” part in your comment seems to be simply incorrect. Of course you still need the fonts, UTF-8-aware reader, graphical display, a monitor, your eyes, etc…

                              2. 1

                                My opinion is yes: make an encoding to rule them all, as it permit to store any character code point, and make all other 8-bits encodings useless, while still being compatible with ASCII. The issue is that it is very widely accepted, but not 100% yet (after all this time (!)).

                              3. 5

                                vim -> vi is not an ‘upgrade’.

                                1. 2

                                  It might be an ‘upgrade’ in subjective old-school coolness, not a technical one.

                                2. 3

                                  I’ve done the very same thing a couple of years ago. I also went from zsh to ksh and moved to other, simpler tools. Started using ed, too :^) I’m no longer spending^Wwasting time tweaking yet another feature. I must be getting old or something.

                                  1. 2

                                    why ed?

                                    1. 2

                                      ed is a REPL-based editor: it works the same way as the command line, and you now have the same universal interface everywhere.

                                      Also, a lot of “plugins” can be used it ed, with the shell escape (!):

                                      • Emacs Magit / vim gitgutter: !git diff
                                      • git fmt: <range>!fmt
                                      • :make: !make

                                      …and so on. These are not plugins, but as the output stays after the command is executed, you can display the few lines affected by that make error, jump to that git hunk you want to change… without making the backtrace / git diff go away: it is in your terminal scrollback buffer.

                                      In the end it feels natural (but clunky to edit stuff within a line: using s/tpyo/typo/ all of the time!) and integrates fairly well with the shell.

                                      You can try it anytime with the Q keybinding in vim, and try ex(1) (EXtended ed):

                                      <range><command><argument>
                                      
                                      • 1m4 - Move line 1 after line 4
                                      • 1,4t8 - copy line 1 to 4 To line 8
                                      • :set nu - convenient for working with lines range
                                      • 1,5 - print lines 1 to 5
                                      • z - scroll one page down
                                      • [Enter] - scroll one line down
                                      • [Ctrl + D] - scroll hale a page down
                                      • z= - display context around current line (very convenient but not in ed)
                                      • s/// - you know it already
                                      • /pattern1/,/pattern2/!fmt - format lines between these 2 patterns
                                      • 1,5g/pattern/d$ - delete all lines with pattern between line 1 and 5.

                                      The bonus to knowing ed/ex is that you have access to these commands in vi/vim in cas you need them.

                                      1. 1
                                        1. Distraction-free - you get an error message about a specific line number and you simply work on that line, give or take 1 up/down.
                                        2. It is available in bsd.rd - vi isn’t.
                                        3. Why ed(1)?
                                        4. Ed Is The Standard Text Editor

                                        :^)

                                    2. 3

                                      I remember leaving a vi window open on my AT&T 3B1 “UnixPC” because I didn’t know how to exit it.

                                      Years later, I wrote chapters on how to use vi for a couple of Solaris certification study guides :D

                                      1. 2

                                        nvi v1.* is horribly buggy. There is nvi2

                                        https://github.com/lichray/nvi2

                                        I do wish it could be ported to more platforms.

                                        1. 1

                                          I am not much of a nvi power user. what kind of bugs are there? also, thank you for sharing nvi2 – I’d never heard of it until now.

                                          1. 1

                                            nvi2 is mentioned in the linked post :^)

                                        2. 2

                                          I was forced to switch to vi (from xemacs) at $JOB back in 2003. It was mostly vim with the occasional vi on IRIX. Then I read the source for vim. Truly horrible. Since then I’ve been using nvi, vile and xemacs+viper. They are all acceptable vi clones for me. Also, as I grew older, the need to have fancy configuration also diminished. These days, I run with almost no config except for a nice font and fg/bg colors. Of course, I use a text editor only for quick edits and for writing text.

                                          1. 1

                                            Fighting emacs users must be getting boring.

                                            1. 1
                                              ↳ caius$ ls -l /usr/bin/vi /usr/bin/vim
                                              lrwxr-xr-x  1 root  wheel        3 10 Dec  2016 /usr/bin/vi -> vim
                                              -rwxr-xr-x  1 root  wheel  1745984 29 Apr 02:59 /usr/bin/vim
                                              

                                              macOS disagrees with you ?

                                              1. 1

                                                I resisted switching from vi (nvi on Linux, vendor vi on various UNIXes) to vim for years.

                                                I’m older and wiser now.