Light and Dark

Light and dark. No, not a moral quandary-type exposition, just literally talking about colour relationship of background versus foreground from the perspective of the terminal emulator of the command line interface (CLI).

The CLI is my most comfortable way of operating a computer. This has been true since my first interaction with it back in the days of MS-DOS, even with the existence of DOS Shell, Windows 3.1, and beyond while staying within the Wintel ecosystem.

The CLI is straightforward to work with. I can expound more of its virtues, but that can be for another post for another day. The quick summary of why the CLI is straightforward (as compared to a graphical user interface (GUI)) is that it is a serialised interrogative type of interaction as compared to the often limited smorgasbord of pre-defined capabilities that is offered in the GUI. This means that the CLI has a built-in read-eval-print loop (REPL) that is akin to how people normally interact with each other.

Now, the CLI and the terminal emulator have gone hand-in-hand ever since it was possible to actually use a CLI with a computer. Old school terminals used to be teletype printers, literally having a typewriter hooked up to the computer to present output while accepting input from the attached typewriter keyboard. Later terminals started using cathode-ray tubes (CRT) which showed the output text as rasterised pixel elements upon a phosphorus mask.

Critically, these CRTs have a default screen colour of dark, which is normal because the phosphor mask is not stimulated by the fast-moving cathode-ray. This is the origin of the traditional ``light on dark'' background for terminal emulators. There is also another practical reason: the cathode-ray striking the phosphorus mask isn't usually the most precise, which means that there is a chance that the collimated cathode-ray can cause a bleeding effect into nearby pixels. So, any lit pixel isn't really as square as it is predicted, but is really somewhat Gaussian distributed with the median being where the pixel is supposed to be, but with light bleeding elsewhere. This means that if the entire screen starts off as being of a light background with dark text, the overall effect is that the dark text will seem much thinner than if the reverse happened.

The evolution towards LCD displays have reversed the operating principles of the CRT. Instead of starting out unlit before having active elements lit, we are seeing that the displays start out being completely lit, with each pixel having filters to alter the colour and intensity of the backing light through filtering. Since the display starts off with a light background and requires effort to change the light background to whatever filtered colour [that isn't white], it became the start of the so-called ``white background saves power'' movement.

Independently, the era of LCD displays also heralded the widespread use of the GUI, with the CLI often appearing in the form of a terminal emulator as opposed to being the ``native'' interface. With most of the GUI being coloured and distinctively not dark, the dark text on light background concept became more dominant.

Recent developments of display technology to that of LED ones (not LED back-lit LCD) has reverted the trend towards ``dark background saves power''.

The LCD/LED displays with their higher precision as compared to the CRT have mostly solved the bleeding colour problem. For me, however, the bleeding colour problem still exists, and here is the big reason why.

I use really tiny pixel fonts. We're talking about 8×8 or 8×16 levels of tiny. I use that a lot for programming because I like seeing more of the source code on-screen, from different sources. Back in the old days, this was fine because displays then weren't of that high a resolution: 1024×768 was considered to be high resolution, especially for a laptop. And that is with a screen display of around 13" diagonally. Rough math says that this is about 1024/(13/5×4)~98 dpi. Compare this with [say] Eileen-II, who has 1920×1080 and has a screen display of around 15" diagonally: 1920/(15/18.36×16)~147 dpi. One might think that this means that the modern displays are 1.5× more dense, but the real ratio is more like 2.25× (you need to square the linear dimensions).

This means that the modern pixel is about less than half the area of the old display pixel.

Qualitatively, it means that if my eyes are getting tired either from staring for too long or from bad ambient light (or a combination of the two), light bleeding into dark becomes a real issue.

So while I generally love light text on dark background, as time go on, I find myself gravitating more towards dark on light background.

Which, after a bloody long diversionary exposition, comes to what I really want to say.

To set that up in Cygwin's mintty, do:

mintty.exe --fg=black --bg=gray100 --cr=black

That gray100 is a way of getting the #ffffff version of white, as opposed to something that is more ``traditional'' which normal humans would call ``off-white'' (#ffffff is called ``bright white'' or ``bold white'' in old school terminal nomenclature). I had tried variants using the old school nomenclature but got nowhere with it, until I brute-forced my way to this solution.

Incidentally, now that I have two diametrically opposite terminal set-ups, I needed a way to tweak my options file in vim to ensure that the syntax colouring isn't fubared. I already used an externally defined environment variable to signal to vim that I was in dark background mode, but the hard part was how to find this out from the terminal in the first place. This hack was done because I could not find any portable way of doing this.

In this context though, I cheated through the use of MINTTY_SHORTCUT: mintty would set that particular environment variable when it is launched via a shortcut. All I did was to make sure that my short-cut for the dark text on light background option was labelled correctly and did some shell-script trickery to set my indicator environment variable.

Works like a charm.

------

In other news, today is the day where up to 2 people are allowed to dine in at a single table in SIN city. The temptation to run out to my favourite bar for an entire afternoon of chilling is high, but it has to be arrested for three reasons:

1. Avoiding the inevitable crowd due to 脱绳猴子 syndrome;
2. Uncertainty of whether my favourite bar (or other favourite food places for the matter) are open for this;
3. Extra risk reduction due to my first vaccination dose being scheduled some time this week.

As promised in a previous post, I am also restarting my OMAD. The weigh-in this morning was sobering---my raw mass was about to get past the 80 kg psychological marker. I have been cheating [myself] by having not done weigh-ins for many days throughout this month.

Time to stop cheating myself. Gotta give my dude future-me a good start.

Alright that's about it for now. I would want to write more, but it's already past the kilo-word mark. Till the next update.