Might be a bit of a struggle without syntax highlighting? Contrast won't get you very far.

You might be surprised how far contrast (and cursive, bold, etc) can get you. Eg: https://github.com/fxn/vim-monochrome

edit: Also, and probably a lot more controversial, code structure matters a lot. No syntax highlighting will save you if your code consists of opaque blocks of text.

I'll admit that that example did more than I expected with the limited tools it has, but it is still rather far from the things full color highlighting can do.

You can, indeed, do a lot without colors. I actually find it a lot less distracting to have various shades of the same color and highlight with bold, italics, and a couple shades of gray. The other day I was wondering if I could add some non-ascii chars to htop's monochrome mode (looked like a pain, will pick it up later) to explore textures instead of colors.

I remember using Think Pascal on the Apple II (too slow to be of any use) but it did a great job of highlighting the structure of the program under the source code. This is what I want syntax/semantic highlighting to do for me.

These screens are higher resolution and can have multiple shades of gray, which is much more than what those pioneers had to communicate with their users.

Horrendously expensive though.

I remember having a chat with Andrew Gerrand at some Go conference, about how syntax highlighting is mostly done wrong, we just got used to it being that way. It's not like we colour words in a sentence based on their type, but we do enjoy tools highlighting misspelled words or grammatical errors.

In my experience syntax highlighting as a tool mostly help with certain classes of errors (e.g unclosed string or comment), not visually tokenising text for me to understand.

I've seen some such uncoloured theme (nofrils) that would de-emphasise either comments or code, and you could toggle between the two states, which I found quite useful in nicely commented files:

https://robertmeta.com/posts/syntax-highlighting-off/

There are a bunch of learnings and a couple of links to references in that article. Ironically one of the most prevalent I experienced was this one, which I found very odd because picking a colorscheme for my $EDITOR is quite literally a choice that would affect only myself:

> People on the internet will get very angry at you if you tell them you don’t like syntax highlighting. VERY ANGRY.

Some of these vim "color"schemes:

    https://github.com/robertmeta/nofrils
    https://github.com/clinstid/eink.vim
    https://github.com/ikaros/smpl-vim

They pair well with vim-airline's "raven" theme.

> It's not like we colour words in a sentence based on their type,

All of today's human languages were developed in a time without computers, pens (and their predecessors) have trouble switching ink color for every word. If goose quills and inkwells could change color as easily as computer monitors, I bet there would have been at least a few languages that use color to denote meaning.

Somewhat tangential: but I love the LiquidHaskell demos, mostly because they show what would be possible if our tools would just be a tiny bit smarter.

Example:

    1. Goto here: http://goto.ucsd.edu:8090/index.html#?demo=Order.hs
    2. Run Check, it should turn green
    3. Break the code, e.g. turn around the >= sign in line 147
    4. Run Check again, it will turn red and highlight line 147 and 148

What happened here?

We told the compiler that elements in an ordered list will be in increasing order (l.119). Now the compiler is able to check that constraint and by turning around the comparison we violated the it.

Ie by telling the compiler a tiny bit about our goals (have ordered lists) it is now able to check that our algorithm is correct.

That example is a little misleading though, since it's using a shade of blue for comments and strings.

But in general, I'd agree, I've been using a monochrome color scheme for a few weeks (although mostly for the novelty) and it's definitely usable. When given the choice, I will use a full-color one though.

Good point. Here's the same image desaturated: https://i.imgur.com/jBCZGEO.png (GIMP -> Desaturate -> Luminance)

I feel like it does not really lose anything in grayscale.

Bonus: On a eInk display black on white is probably nicer: https://i.imgur.com/99DSGrV.png

(Does Imgur allow direct links to images?)

My favorite part of that example is the language it's written in :) I'm sold!

I had to look that up ... is that Euphoria?

As stated above, I think that how the code is structured also heavily influences readability. Maybe even more than syntax highlighting.

Case in point: I was fortunate enough to work on a Haskell project some time ago ... and one of my colleagues from another team at asked me how I manage to make my code look that concise. No secret there, it is just pretty easy if the language is that expressive.

> I had to look that up ... is that Euphoria?

It's Elixir (https://elixir-lang.org/), but wow, Euphoria looks pretty slick too! https://www.rapideuphoria.com/

Ah ... I could have known that ... some of the Haskell enthusiasts around here actually moved on to Elixir some time ago.

I don't care about syntax highlighting, being coding in black and white terminal for a really long time. I care more about screen to be more like paper than screen. LED color screen really hurts my eyes. Coding in natural light on paper would be much better.

I enjoyed using my OLPC XO-1 for writing, programming, terminal usage, web browsing, etc. whilst sat outside on a sunny day. Was certainly a contrast to 'phone screens, which were barely visible, even with a backlight and shielded under a hand!

(The XO-1 uses a different display technology to these e-ink monitors, but the result is similar: a high-resolution greyscale display, lit externally)

While not coding per se, I write fiction on my Boox Note 2 in Wordgrinder through Termux and it’s pretty great (especially if I increase the refresh rate). And that’s an older slower device!