1. 36
  1.  

  2. 24

    I want N kinds of highlighting, for example: F1 is all-black, w/ error lines in red & warning lines in yellow; F2 shows git changes: unchanged black, new green, deleted red, modified orange, &c; F3 is maybe your normal keywords-comments-and-literals stuff, F4 shows test coverage: black uncovered, green passing, red failing; F5 is black with TODOs and FIXMEs in yellow … . On and on, N kinds of highlighting. I want to switch between them freely, and fast. I want a minimap view so that I can hit F1, look for red/yellow, then switch back to normal F3 (for example). Of course, this is just a nice thing to have.

    1. 14
      • Highlight functions coming from outside modules
      • Highlight functions that appear in a given stack trace
      • Highlight deprecated functions
      • Highlight function uses where the function definition has a FIXME in the comment block above it
      • Highlight functions with if branches in them
      • Highlight functions which could potentially call functions with if branches in them
      • Highlight functions with a monad in the type signature
      1. 5

        This is actually a very neat idea which I might want to start experimenting with. Should be trivial to write an Emacs mode for it.

        1. 2

          I would like to take this back a notch, because I think it’d be better:

          f1 is normal text view; f2 is git changes in the current file (literally output from git diff); the rest are satisfied nicely with vim’s quickfix window.

        2. 15

          Upvoted because interesting topic and because it’s authored by the poster. I appreciate to see that on lobsters!

          Assuming that the author is reading the comment, I have some feedback though:

          Content

          There is not much new I learned from the article, but to be honest, I have already read a lot of stuff about syntax highlighting and color schemes. I used vim without syntax highlighting for many years (out of conviction), but semi-recently switched back to having it turned on without looking back.

          What I never found is hard data on what color scheme / mechanism of syntax highlight (or lack thereof) is objectively most readable, if that is even possible. The linked article is no exception in stating something for a fact without supporting evicence.

          I like the idea of having a color scheme that doesn’t overdo the highlighting. Which theme are you using, or did you assemble your own theme?

          Usability of the website
          • The link is not a deeplink to the article, when you open the page, all the articles are collapsed. It took a bit of mental effort to realize that this is the case. I almost closed the tab again, without reading the article.
          • On mobile the picture is very small and it can’t be zoomed. It would already have helped to put it in a link tag that points to the image file.
          1. 8

            Re: Usability, I actually did close the tab and only reopened it when I saw your comment explaining what was going on. I thought the site was just broken, the mouse cursor never changed into anything that looked clickable (like it usually does for links).

            1. 7

              The linked article is no exception in stating something for a fact without supporting evicence

              true, these are just my musings.

              Which theme are you using, or did you assemble your own theme?

              overdone colors (almost everywhere) have driven me to assemble my own monochrome themes for every program I use:

              you can find the relevant configuration files here, the vim color scheme is a fork of another popular “no nonsense” color scheme.

              Usability of the website

              noted. ill make changes. thank you for your feedback!

              1. 1

                I’d love to see a Sublime Text theme. Oh, and a Nova one too, once Panic releases it.

                Nice concept!

            2. 10

              Why dim the comments do much? In my opinion they should be highlighted more than the code.

              1. 7

                When it comes down to it, the code is what defines the behaviour of the program, not the comments. The bugs in the code are the ones that degrade your users experience, not the bugs in the comments. The security flaws in the code are the ones that give unauthorised users access to sensitive information, not the security flaws in the comments. The performance issues in the code are the ones that cost you an additional server, not the performance issues in the comments.

                I agree the screenshot in the article is clearly taken by a person whose monitor is not well calibrated, because surely that gray text must look brighter to them than to us (on my reasonably well-calibrated monitors, it’s nearly unreadable.) But I don’t think “comments should stand out more than code” is ever a practical approach.

                1. 3

                  Either the code is wrong or the comments are.

                  1. 2

                    My rule of thumb: If comment and code disagree then usually both are wrong. 😉

                    1. 3

                      I said “or” not “xor” :p

                    2. 2

                      Non-controversial response: whichever is the case of the two, the code is what matters to the end user, because that is what they see.

                      Philosophical response: to the end user, the code is never “wrong” in relation to the comment. It might be bad, but it is always a description of reality, and therefore cannot be wrong. It is always the comment that fails to match what the code says. It is always the comment that is wrong. (Even if you may have wanted the reality to reflect the comment, when there’s a mismatch, reality will always reflect the code, never the comment.)

                      1. 2

                        It’s the developer’s code, right or wrong: if right, to be kept right; if wrong, to be set right.

                        For that you need to know not one but two things:

                        • What the code does. For that, you study the code. But it’s not enough on its own.
                        • What the code should do. When the code is correct, what the code does also describes what it should do – but you won’t be able to check that it’s correct. When it’s wrong, the code misleads you about what it should do.

                        All error detection depends on redundant information: you need it to detect inconsistency. So we add extra information channels next to the code. From least to most expressive:

                        • descriptive function and variable names (in the code file)
                        • comments and doc strings (in the code file)
                        • external documents (specs, meeting notes, e-mails, chat logs) (hopefully in the repository, but)
                        • outside information (in the programmer’s brain)
                        • outside information (spread over your colleagues’ brains)

                        If you remove comments from that list, you’re left with things that are either less expressive, or more likely to be missed by somebody working on the code.

                        1. 1

                          You seem to agree with me that the code itself is the most expressive informer of intent. That’s why I prefer it to be emphasised over comments, rather than vice versa.

                          1. 1

                            No, no, code is where I can’t be sure, without corroborating information, whether it’s only implementation being expressed or also intent.

                            Not sure when you’ll read this, or what time zone you’re in, but before it’s too late: happy new year! May 2020 bring joy, peace, comfort, and wisdom to you, and to all of us in the world.

                    3. 2

                      If you have trivial comments like “now let’s go add two numbers here” then sure, dim them. But if your comments are actually useful (or even critical) for pointing out potential problems or caveats, then making them stand out makes much more sense.

                      See e.g. https://jameshfisher.com/2014/05/11/your-syntax-highlighter-is-wrong/

                      I don’t think “comments should stand out more than code” is ever a practical approach.

                      It’s the default in Vim; it works pretty well.

                      1. 2

                        I agree in principle. I even ran that setup for a few months. In the end, though, it mainly caused two things:

                        • Comments distracted me from code and made me miss obvious flaws in logic; and
                        • As a consequence of the above, I caught myself writing fewer and fewer comments, even in situations they would have been useful – they were just not useful enough to outweigh the distraction they made when they were excessively highlighted.

                        I realise while writing this that there is an argument to there being a fruitful middle ground, where the comments are only slightly emphasised over code, or only slightly deemphasised under code, but I couldn’t be bothered searching for that optimum.

                      2. 1

                        I agree the screenshot in the article is clearly taken by a person whose monitor is not well calibrated, because surely that gray text must look brighter to them than to us

                        This is probably the case, I have noticed my color scheme being off on other displays.

                      3. 4

                        I share the same opinion. My highlighting config makes comments more prominent. My thinking: A human being has taken the time to try to communicate to me in English something important and non-obvious. I think this may vary with the language or programming community in question, but in full stack web development, [I’ve found that] comments are very spartan, and when they’re in there, it’s because of something very important, or tricky, surprising, or which needs explicit justification.

                      4. 10

                        I don’t really agree with “rainbow barf.” The last screenshot is the one I want to look at. I can clearly see what is a function call and what is a variable. Code highlighting does make things way more readable for me. Could if be more helpful if it’s toned down? .. I mean, maybe, but it doesn’t hurt me that it’s colorful.

                        That’s one thing I really love about Gentoo’s package manager. The fact that everything is colors makes it really easy to see current version, new version, active and inactive USE flags, etc. Even thought apt has some colors now, it’s now much and not very useful.

                        I question the author’s design choices honestly just looking at the site. A one page layout where you click on an article to expand it with no permalink to the article itself? It’s not even obvious that it’s a link because of the way it’s implemented. Just .. bad design.

                        1. 3

                          The last screenshot is the one I want to look at. I can clearly see what is a function call and what is a variable.

                          Maybe I consume code differently than others - but it doesn’t matter to me if xyzzy is a variable or a function call. To understand it I need to see its type, where it is used in context, etc.

                          Similarly, why highlight the function call in xyzzy.frobnicate()? Something was frobnicated, great, but I have to review that function to understand what it does. Does it help people to see that part “standing alone?”

                          The only syntax highlighting I’ve enabled for regular editing are strings and comments. I do like context-specific highlights in small doses - REPL output in my buffer, lines failing linter checks, VCS Christmas tree - but that’s it, really.

                          I wonder if this is because I’m around multiple divergent software products in different languages and I don’t get to stay with one long enough to recognize it without reading the parts I need to work with in entirety every time. Maybe if I was dedicated to one code base I would think differently.

                          it doesn’t hurt me that it’s colorful.

                          Having a combination of terrible eyesight and the attention span of a gnat probably dooms me to avoid syntax highlighting :)

                        2. 3

                          This is basically what I do except I only differentiate comments and code. I highlight comments in a colour rather than dimming them down. I used to highlight strings too, and I’ll probably go back to doing that as I do find myself forgetting to close strings sometimes without the visual cue. Otherwise I feel like the shape of the code itself is enough to make it readable. Write good simple code and you don’t need over the top highlighting. Highlighting is good, just like everything, in moderation. The norm unfortunately it’s anything but in moderation.

                          1. 3

                            Taking the time to point out that as more and more command-line tools use color highlighting either by default or enable by default by your OS (GNU ls, GNU grep, git, etc), having a background color on your terminal that’s even slightly unusual (not white/black/solarized) makes things get irritating quickly.

                            I can’t tell you how many times I’ve had a nice color for my background but I went and grepped for something or did a git diff and couldn’t read the output.

                            >:(

                            1. 3

                              I assert that syntax highlighting is not so different from other visualisation problems.

                              Your palette choice should be informed by how many categories you want to distinguish between; or if you want to indicate a continuous value (and if so, is it diverging (e.g. good, no-change, bad), or not (e.g. execution count)).

                              I think a greyscale palette is only going to be appropriate for showing a small number of categories (can’t distinguish many greys) or a non-diverging continuous value.

                              Thanks to you and especially to @unwind for making me think, though.

                              1. 3

                                I wrote about this before: https://vfoley.xyz/purp/. I created a theme for myself that isn’t the prettiest in the world, but is quite functional. Only four constructs are syntax-highlighted: string and character literals, comments, the name of a function in a function definition, and dangerous stuff. The rest uses the default text color.

                                1. 2

                                  I’d like to try something like this out… is there a vim ‘theme’ that demonstrates the ‘color free editor setup’?

                                    1. 2

                                      It might be his vim-colors-plain theme:

                                      https://github.com/nerdypepper/vim-colors-plain

                                      1. 2
                                        1. 2
                                          1. 1

                                            to add to some of the others

                                            Though I use vim-colors-plain. I’ve really enjoyed it.

                                            1. 1

                                              I wrote this for myself: everything is yellow, strings are red, comments are grey.

                                              I remember when I started dipping into that idea – a veteran programmer ridiculed the idea of syntax highlighting. “I know what my language does, I don’t need training wheels for my editor!”

                                              “What a ridiculous idea!” I thought. “Of course it’s better and easier with colours. I’ll try without them for some time just to make sure he’s wrong.” Fast forward a few weeks… he wasn’t really wrong. I’m not convinced syntax highlighting really does anything for clarity and ease of working with code. Syntax is usually instantly recognizable from the code layout alone.

                                              What I’d really like to see is an editor that can highlight stuff that make semantic sense, or are meaningful in runtime. Make my slow code red and fast code green, like a highlighting code profiler, for example. Find the code not covered by unit tests and turn it red. Highlight the variable that was written to, but never read in the last 20 runs, stuff like that.

                                              I can recognize syntax of my “native” programming language just fine – it’s the subtle semantics that elude me.

                                              1. 0
                                                :syntax off
                                                

                                                It disables syntax highlighting.

                                                1. 2

                                                  Well, sure, but the example in the article doesn’t have all coloring disabled: https://files.nerdypepper.tech/bF.png

                                                  1. 3

                                                    By chance I’ve been doing almost exactly the same as the OP has with my Vim colours. I just can’t stand rainbow vomit in my editor.

                                                    I use it with an xterm using solarized colours.

                                                    As you can see, it’s not really release-ready.

                                                    (The copyright comment is that of the theme template I started with).

                                                    1. 1
                                                2. 2

                                                  Meanwhile the first thing I do in a new environment is turn off all syntax highlighting. If I want to find a term, I search. If I want to see comments, I visually scan. I turned it off as a joke a few years ago, and have not looked back.

                                                  1. 2

                                                    I agree so much with this. I want to use one of the popular colour themes simply because they are usually well supported everywhere and define defaults for all sorts of things. They’re also univerally in the “unicorn rainbow barf” camp, which means I keep having to hack my own theme and continually expand support for it.

                                                    1. 2

                                                      I played around with this a while back in Emacs. I haven’t kept it as updated as I’d like, but my grayscale-theme is an experiment in making “important” parts of the text brighter and less important parts darker. The idea of which I took from the Duotone Atom Themes. It was meant to be a higher quality version of the base16 grayscale theme (I also maintain the base16 emacs themes).

                                                      I’m happy with the result, but I still find differentiating by color to be useful.

                                                      1. 2

                                                        Like others, I’d like to see this discussed further.

                                                        I probably have two or three hot takes disguised as blog posts on the subject of a certain color scheme billing it’s purely subjective choices as ‘scientific,’ and observing hackerdom generally not calling it out on its BS.

                                                        1. 1

                                                          IMO the best syntax highlighting is the syntax highlighting that works for you.

                                                          1. 1

                                                            I created https://github.com/ScriptDevil/eltbus-theme several years ago on the same principles. https://i.imgur.com/bCyoytv.png is a screenshot. I have since switched back to the default emacs theme but some people may like it.

                                                            1. 1

                                                              Some time I have found theme Sidonia that diverged from it’s original design so now I maintain Blame theme that adheres a little to these ideas.

                                                              1. 1

                                                                This looks interesting - is there a vscode plugin, or maybe a popular theme that works across editors, that anyone can recommend? I found Verdandi which is grayscale-only.

                                                                1. 1

                                                                  For another unusual idea for syntax highlighting, see “semantic highlighting”, as described in Coding in color. It means coloring each variable’s name with its own unique color, the better to spot where variables are reused. For example, the users variable in a piece of code might be red and the loggedInCount variable might be blue. I would assume semantic highlighting works better when you also use a theme that uses fewer colors of its own.

                                                                  I’ve never tried using semantic highlighting myself, but I see there is a Vim plugin semantic-highlight.vim for it. JetBrains IDEs support it too. VS Code, however, doesn’t support it yet.

                                                                  Another syntax highlighting style to remember when thinking about the ideal system is “rainbow parentheses”, which many people use when editing Lisp-family languages. See this random README for some example screenshots. With rainbow parens, delimiters such as parentheses ( ) are colored differently depending on their level of nesting. Most editors have plugins to support this.