Funny how they use the term "City of Darkness" a few times, without ever referring to the book "City of Darkness", by Greg Girard and Ian Lambot, from which most of the pictures in the article come.
The good thing with the 256c palette is that colors in the 16-255 range are fixed, which gives us a very high level of confidence that 146 will be a muted violet and so on. This is very useful for colorscheme developers because it allows us to provide a pretty good and consistent experience across the widest range of terminal emulators.
If the 256c palette is generated from a -- potentially wild -- 16c palette then there is no guarantee anymore that 146 will indeed be the 146 I expect.
Turning 16-255 into the same kind of minefield as 0-15 seems very misguided to me.
I know 16 colours is limiting, but one of my biggest pet peeves is CLI / TUI developers creating their own custom themes using colours outside of that because odds are, they’re going to generate a colour scheme that is harder to read for a lot of people with visual impairments, people who prefer a white or coloured background for eye comfort, people are dyslexic and find non-black backgrounds easier to read, and others with visual difficulties, reading difficulties, or those who just like a different colour scheme per project or environment they’re working in so they can multitask more easily.
And the developers answer to this loss of control is to create multiple colour schemes and allow the user to configure the app. Which then means their users have to set up their terminal defaults and then configure every fscking app that ignores those terminal defaults(!!!) instead of defining their required colour schemes once in the terminal.
People use the terminal not because it’s pretty but because they find a text interface more efficient. If you want to make pretty things then build a web frontend. But please do not break my terminal because you feel the need to impose on me your own favourite colours of the hour.
I agree. I always customize the blue color on my terminal because dark blue on black is completely unreadable to me (and I'm not even color blind!). For some reason, every single terminal emulator defaults to a blue that's unreadable on a black background (I think typically #00f).
If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
Not really, because the dark yellow (not brown) is used... it's similar, but not the same in most terminals... brown as dark yellow for cga was a kind of short to a different color mix than the natural position which most terminals now use... actual screen effectiveness/brightness is different as well.
Kind of anal about this since I started with a lot of CGA and EGA displays when I was in my late teens and early 20s and relatively involved in the ANSi art scene.
Here's a related project I'm working on for playing doors in a web browser.
I have no idea if this was the reason behind turning the dark yellow into brown, but the brown was a much better looking color for DOS games so it was a good call
They could also have done something about the two magentas though... E.g. made one of them orange?
I think it was just determined that brown would be more useful than the darker yellow in practice. Other xterm colors are also a bit off from CGA/EGA/VGA DOS colors.
If I was the maintainer of a terminal emulator, I would see a quite obvious way to improve the situation for my users: change the default colors so that dark blue is brighter.
There's no obvious way to unilaterally improve the situation across the whole ecosystem, that's true. But I don't understand why individual terminal emulator maintainers don't fix it for their users.
Because it means making choices, breaking assumptions, etc.. They have made it user-customizable so they don't have to go through all that.
FWIW, the current de-facto standard is set by xterm. Here is a relevant excerpt of its source code:
! Disclaimer: there are no standard colors used in terminal emulation.
!
! The choice for color4 and color12 is a tradeoff between contrast, depending
! on whether they are used for text or backgrounds. Note that either color4 or
! color12 would be used for text, while only color4 would be used for a
! background. These are treated specially, since the luminosity of blue is
! only about half that of red/green, and is typically not accounted for in the
! RGB scheme.
!
! Blue text on a black background should be readable.
! Blue backgrounds should not be "too" bright.
!
! Originally color4/color12 were set to the names blue3/blue
!*VT100*color4: blue3
!*VT100*color12: blue
!
! They are from rgb.txt respectively:
! 0 0 205 blue3
! 0 0 255 blue
! However, blue3 is not readable on a black background.
!
! Another choice was from the Debian settings:
!*VT100*color4: DodgerBlue1
!*VT100*color12: SteelBlue1
!
! From rgb.txt:
! 30 144 255 DodgerBlue1
! 99 184 255 SteelBlue1
!
! Some users object to this choice because the background (color4) is brighter
! than they are accustomed. Others point out that the different weights for
! the red/green components make it appear to be not really blue. Finally, it
! provides poor contrast against color13 and color14.
!
! The current choice uses equal weights for red/green (effectively adding a
! gray to the result). It is brighter than the original choice, and provides
! more contrast between color12 and color13, color14 than SteelBlue1 did.
! Contrast of color4 against black is slightly improved over the original.
!
! Some refinement is certainly possible (you are welcome to try) -TD
There are fewer blue cones in the fovea centralis than there are in the surrounding parts of the macula, so humans can't resolve details as well in blue light.
The sensitivity of S cones is also simply much lower than that of the M cones. It's clear that pure (0, 0, 1) blue is perceived as vastly darker than pure (0, 1, 0) green. Blue light must be about 10x brighter (in linear intensity) than green light to be perceived as equally bright; the brightest full-saturation blue in sRGB looks about as bright as the very dark green (0, 0.1, 0). The contrast on black background is incredibly poor.
Which is why people who understand color tend to add a bit of green in to make a color which still looks deep blue but is much brighter than what #00f looks like
And I filed a PR because an author used yellow and hadn’t assigned orange to any purpose, which is actually legible on a white terminal where yellow never is.
If I make a terminal emulator, I would probably not support true colours in text but only in pictures (and it would be possible to disable pictures). I probably would not implement 256-colours either, because I agree with you; the user configures their own colours to use, and the terminal should use them. For text, only sixteen colours can be used.
Similarly, the user can also set their own fonts for the terminal, just as you can with colours and other functions. (However, some programs will have a reason to configure the fonts and palettes for the specific use, although most won't and even if they do the user might disable those features.)
A program can have an option (possibly by environment variable) to disable colours entirely; this might be necessary even if you can disable colours in the terminal emulator, because a program might want to use such things as reverse video, underlined text, etc to indicate some things when colours are disabled. (Disabled colours can also be useful if you do not have a colour display or if you want to print out a screenshot without a colour printer.)
gdb (the debugger) sometimes prints dark blue text on a black background, which is unreadable. I customize the dark blue color when possible in VTE's due to this, but it's not always possible everywhere
But I wonder what the developers of gdb were using that made them not notice this
yes, this.
the reason i use wolf (firefox fork) is because i can easily disallow styles overriding, font overriding, and use bitmap fonts. nothing else.
now that react devs finished destroying the web they have to impose their superior taste into terminal through 800mbs TUIs.
Color usage in the terminal should be largely semantic, not stylistic.
Speaking for the group of people I know and work with, we don't want a "consistent experience" and hate TUIs that try to manhandle the color palette. Use color sparingly and with intention. Respect that different people have different settings.
First, I make third-party Vim colorschemes, not app. People install my colorschemes because they like the colors, not because I'm a monster with a gun pointed at their face. No one is harmed. No one is forced to do anything they don't want.
Outside of my text editor, where colors matter a lot to me for syntax highlighting, I'm definitely in the NO_COLORS camp (and in the NO_EMOJI camp, nowadays).
> Color usage in the terminal should be largely semantic, not stylistic.
I wholeheartedly agree but 0-15 sadly have zero inherent semantics, which is the single reason behind every terminal colors-related drama since forever: developer choses 9 to highlight an error message because it is generally a bright red by default --> user sets 9 to whatever makes sense to them --> error message is illegible.
It would be much better if application developers (and web developers, too) -only- had access to semantic color labels like TEXT, BACKGROUND, ERROR, WARNING, INFO, HIGHLIGHT, and so on, rather than red, yellow, blue, green, black.
I don’t want my applications to decide “this element must be red text on green background.” I want my applications to annotate the UI with things like “warning message” and “title.”
That could be done with a few influential terminal emulators adopting a consensus extension to ISO8613-6, like this: ESC[38:99:‹purpose›m for foreground, ESC[48:99:‹purpose›m for background.
e.g.
Foreground Background Purpose
----------- ----------- -------
ESC[38:99:0m ESC[48:99:0m normal ( same as ESC[39m and ESC[49m )
ESC[38:99:1m ESC[48:99:1m emphasise
ESC[38:99:2m ESC[48:99:2m de-emphasise
ESC[38:99:3m ESC[48:99:3m error
ESC[38:99:4m ESC[48:99:4m warning
ESC[38:99:5m ESC[48:99:5m caution
ESC[38:99:6m ESC[48:99:6m notice
Then people (themes) could easily choose foreground colour or background highlighting for particular roles. Some terminal emulators might also choose to configure other stylistic choices like bold, italic, etc.
(I believe ISO8613-6 defines sub-modes 0 through 5 (te;db), with 2 (rgb) and 5 (256-color indexed) being most widely implemented. But some terminals historically mess up : and ; in CSI sequences, and I know at least one would interpret ESC[38:6:1m as ESC[6;1m (blinking bold!), so here I pick 99 (ECMA-48 defines modes up to 65).)
After thinking about it a bit more, I think the specific details of that (i.e. inventing an extended colour mode) are not ideal.
One alternative: Assign semantics to colour indexes above 256.
Both of those have the disadvantage that they separate foreground and background colour, but a user really wants a combined semantic presentation. For instance, a user might want a warning message to be black text on a yellow background, and not have to rely on the program remembering to set both foreground and background to ‘warning’ colour.
So another possibility is just to invent new SGR numbers, e.g.
Control Purpose
------------ -------
CSI 2 0 0 m normal (undoes any CSI 1 x x m)
CSI 2 0 1 m emphasise
CSI 2 0 2 m de-emphasise
CSI 2 0 3 m error
CSI 2 0 4 m warning
CSI 2 0 5 m caution
CSI 2 0 6 m notice
⋮
Then the user can configure those as they please with any combination of foreground, background, weight, slant, etc.
I'm now thinking about writing up pros and cons of alternatives.
I like this idea, although I think that they should be only one code, which might program both the foreground and background (and font styles if applicable), rather than separate codes for foreground and for background.
My proposal would be to define a set of intents for 0-15 with sensible defaults and let terminal themes assign any color they would like to those. 0 would be background, 7 for foreground , 1 for highlight, 3 for titles, 4 for frames and from there work on backgrounds also..
I prefer my background dark so light colorschemes are not really an area I've explored seriously. Also, dark colorschemes are much easier to design than light ones due to the disproportionate amount of light a white, say, background emits compared to the amount emitted by text. It dramatically reduces the number of colors you can use.
We have many millenia of books using black text on a white background with various colors added, why are computer monitors all of a sudden so special and annoying
Good TUI's arent bad for POS terminals and the like, where speed it's king, kinda like airports where the latency it's a matter of life of death. For everything else, just look at IBM: you have the old TUI with 3270 terminals and web 'bindings' to these to accomplish the same exact task but with a GUI interface.
But OFC some airport assistant has an AS400 console on it and that's it sending commands at blitzing speeds. These interfaces have sense there; but not for a modern desktop OS shell as the main debugging environment.
Yes, and giving developers control over colors, text size, typeface and so on has also been a usability and accessibility disaster on the web, too! The user should have this control.
> which gives us a very high level of confidence that 146 will be a muted violet
Is there anything you can do with that information though? This piece of information only becomes useful if you know what colour the background is. And you should also know the colour of text and everything else.
What if the background is muted violet? What if the background is white and the foreground is muted violet? I don't want you to ever use "muted violet" in my terminal, since you have no idea what colours there are in my terminal.
I make Vim colorschemes so I'm fully in control of all those aspects. If I decide I want a given token in muted violet it is because I know that it will works well with the background… that I have defined myself.
The exact values of your 0-15 don't matter to me and they don't matter to you either, because you chose to use my 256c colorscheme to begin with.
Then you're not really covered by the article? A colorscheme is all about... color. A TUI is about the content and function. I think there's room to have user-defined 256 palettes that are used by default, while colorschemes can use true color and be chosen by the user if they desire.
I would posit then that this article simply doesn't apply to you at all. The feature being described is targetted at users who are effectively developing their own schemes (albeit in a rather simplified automated manner). If I'm taking something off the shelf, I'm using the appropriate recommended base16. I have no expectation that a wild base16 is going to align with any 3rd-party's curated scheme.
I do understand that this logic isn't always going to click with people given the differing contexts of a terminal-wide -vs- app-specific (i.e. vim) approach, but again: that disparity seems either a legacy issue (caused by things like this 16-256 mis-alignment) OR simply a philosophical difference (whereby people who customise at the term level shouldn't at the app level & vice-versa).
This will be fascinating to see in practice, with ghostty for example shipping these changes! I expect that the concern you have here will largely be for naught, with some exception. What are some terminal apps you think might be affected, what are test cases?
I didn't read in fully, but what I was thinking in my head is not that we would just totally replace the rest of the colors with arbitrary palette. But that we would sub in better versions of the palette that also used user colors as the base. What was magenta is derived from what the user picked from blue and red.
There's always been such tension between design/creative and users. Apps & designers want their own brand identity, want creative control to make things just so. And are willing to throw user preference & desire on the pyre to get that exacting control. Personally that was always rubbed me extremely the wrong way; I would way rather allow some weirdness & funkiness in, if it leaves the user in control. But I understand the risk aversion, understand the Murphy's law corporatism that makes people and companies want to build strong laws that forbid anything but strictly approved systems, for fear that things go wrong. I understand. But I also things that's a dogshit world to live in.
0-15 are, as I said, a minefield because they are user-customizable: there is no guarantee whatsoever that my user's 1 will be the same dark-ish red as mine… or that it will be dark-ish… or that it will even be vaguely red-ish. It is actually somewhat fun to design colorschemes within those crazy constraints but oh well.
On the other side of the spectrum, truecolors is a nice idea in principle but support is still spotty and inconsistent. In theory, this gives me, the designer, full control over the colors used in the UI, which is a good thing for us and for my users. In fine, if I want my colorscheme to be usable by most users, then I can't blindly rely on this.
Which leaves me with 16-255, which are more widely supported than truecolors and, more importantly, dependable. They have problems, as mentioned in the article, but their _fixed_ nature gives me confidence that the background color of the status-line, for example, will look exactly the same -- and exactly how I want it to look -- in all my user's environments. Which, again, is good for my users and for me. Losing that confidence is what worries me, here.
Like you said, maybe 146 will still be a muted violet —— just not exactly the same -- but I'm not sure about this and I think that, at the minimum, this "feature" should be put behind a checkbox/flag.
This is the main issue as I see it. Obviously I'd prefer to need to customize less, but as long as I have the option to override the defaults, I don't care much about what those defaults are. But the concept of "branding" flies right in the face of this.
For far too long I'm ashamed to admit, I would use vim with the adventure time theme on iterm2. Looking at it now I'm shocked my eyes didn't bleed more. I think the worst part was that visual mode was neon yellow bold text with neon pink bg. Relying on visual mode quite a bit while using vim I was self inoculating my subconscious with stills of a poor Jackson Pollock imitator while on multiple different amphetamines. Hopefully I find out my resistance soon.
> and consistent experience across the widest range of terminal emulators.
Instead of aiming to provide a "consistent experience", you should instead prioritize providing consistent functionality, while avoiding impeding users' control over their own particular experience.
No, because I don't develop programs. I make third-party Vim colorschemes that users install because they like the colors. There is no impending happening, here.
Yes, I know that (see the venerable https://github.com/trapd00r/colorcoke, etc.) but those tricks are not used widely enough for them to be a concern. Using those tricks is also a deliberate choice so it is definitely on the user if my lovingly crafted 256c colorscheme is broken.
Having all terminal emulators run the equivalent of colorcoke without asking the user is not a very bright idea.
I'm sorry, but I find this mentality from app developers extremely annoying.
I personally prefer light themes everywhere, both in IDEs and in the terminal. I thought that just choosing my own color scheme for 0-15 would give me the color pallette that I prefer, but because app developers like you for some reason decided that you know better what colors do I prefer, this is actually not enough. I also have to configure each TUI application separately to have the color scheme that I like.
And I do not understand why people do it. Like, why would you deliberately break the universal customization system and force users to use your own, specific to your app?
Honesty, each time I encounter an app that uses 16-255 colors, I feel like someone just violated my personal space and intruded into my chosen color pallette with their own colors that don't fit.
I'm not an app developper. I make third-party colorschemes for Vim, which I assume are downloaded, installed, and used by people on their own volition, after they have looked at, and liked, the screenshots. Moreover, I take great care to make sure they are still usable in 16c, within reason.
Because all my work is based on 16-255, I can actually guarantee to my users that, given a properly configured terminal emulator, they will get the colors on the screenshots.
If I can't rely on 16-255 to be fixed anymore, then I won't be able to make any promise anymore. In practice, it just means adding a caveat in the README.md, but I'd prefer not to. Here's hoping this breaking change gets hidden behind a checkbox/flag.
That's okay. Because the user has to reach out and choose a colour scheme they like, you can assume if they installed your colour scheme, they like the colours.
Is that really optimal? It is already true in that case that your colour schemes do not work for people with opinionated colour settings. Isn't this just relying on a quirk? The point of not using truecolor is to respect the colour preferences of the user.
Semantic styles limit the use - not all interfaces need e.g. "error" context. Take, for example, Task Warrior interface. There is no place for the "error" semantics in it. But there's a place for "critical task" semantics, which is usually also some shade of red.
I like HN when it is leans toward "a place for everyone to talk about tech". Not so much when it derails into "a place for technologists to talk about anything".
You think tech is not going to be affected by this warmongering?
I think it's one of the biggest threats, if not the biggest, for US tech startups wanting to sell to customers outside of the US.
I don't consider myself very politically active, neither are my friends. But we are all looking to detach from the US and its companies. If you are a fledgling startup, in the coming weeks you might just lose out on many of your potential customers.
Exactly! Digital sovereignity is something we talk about a lot in Europe now since Trump is back and it's already causing german states to go full OpenSource and Microsoft-free. Chaos Computer Club called out the national "Digital Independence Day" this year, it's each month's first sunday (https://di.day).
It might not look like much but Trump is also making people realize over here how bad big-tech is for european values and how it's trying to undermine them for profit. This Greenland-thing is a step too much for Europe and seeing how close the techbros are to Trump, that is one thing where we can hurt them, take back our Data.
It is certainly possible that the US tech sector will be affected by the latest US president's brain farts… but I couldn't care less. Not my country. Not my scene.
I'm here for ASCII characters rendering pipelines, scientific breakthroughs, experimental filesystems, random wikipedia links, monospaced fonts, etc., not for silly politics.
I live in Europe and it's interesting to see intellectuals from the US and around the word that are primarily in the tech sector and known to have a broad knowledge of the world debate this topic. Since this could turn out to be the most destructive action of the century so far, considering world economy and maybe also the influence of big tech in europe, i think that is quite valid.
And moderators of big tech companies removing a political post from a front-page of an influential forum while it shows high interest, gratifies my intellectual curiosity even more!
But what to debate? Almost everyone agrees this is stupid, but nobody can do anything.
It's a bit interesting to read the best steelmans, then read how even they're flawed. Apparently the US not only already has a military base on Greenland, but is allowed to build more; and Greenland's resources cost more to extract than they can be sold. It appears there really is no benefit except to anger, scare, and annoy people. What other knowledge or insight did you find?
Surprisingly, there do still appear to be people (or at least one person) here on Hacker News who think America would win and that the EU would simply accept being invaded and do nothing. Like the EU would not decide "fight or die, we
choose fight", nor replace the US with China in trade relationships.
This insight is… the interaction felt like reading a history book, or a novel with an obvious villain.
Feels unreal, like watching 9/11 unfold on TV felt a quarter century ago. Except I get to talk directly to the Other instead of watching translations of their words being quoted on bulletins.
I agree. But when moderation is lenient and everything is allowed, you can't randomly decide to pull the plug on specific topics within a genre that's allowed.
I don't know whether these stories are pulled by HN moderators or flagged by lots of users but there is more than one motive for pulling/flagging stories.
One motive might be to avoid unproductive discussions - many of the comment threads on the Greenland story (which I voted up) were angry and very polarised.
More like the American timeline i.e. "that's the other party I don't like." There is this continual suspicion that if you criticise one lot you must support the other, as if there are only two shows in town.
> Despite his expertise, it's still a mystery how his anonymous persona was deanonymized.
The only explanation is that his OPSEC wasn't as rigorous as you think it was.
Reading the Wikipedia page, the most obvious gap would be the medical treatment he received in 2017. If he mentioned it publicly, then it was basically game over: finding him would have been routine police work at that point. The process that led to the interview by a German newspaper might have been leaky as well. There are so many opportunities.
As a rule of thumb, you can consider that while your OPSEC might _theoretically_ be the tightest in the world, you will eventually have to deal with other people and orgs at some time, who might not care as much as you do. In which case your OPSEC is really only as strong as _theirs_.
> Is it even possible to win a "battle" where you have to be perfect 100% of the time, while the adversary only needs to find one leak?
It is not. Simply because you can only control so much. A few years ago, there was a story about a mafia boss who successfully escaped justice for 20 years… until a Google Street View passed by while he was shopping groceries in a Spanish village. The guy certainly had the strongest OPSEC his money and relationships could buy, but it eventually amounted to nothing in the face of pure randomness.
All you can do is try to compartmentalize as best as you can for as long as you can, but something will eventually leak.
Also, it will be harder…
- the longer you keep it going,
- if it involves others,
- if you are married, have kids, etc.,
- if you have complicated needs (sex, drugs, health issues, etc.),
- if money is tight,
- if you are not geographically and socially mobile,
- if your public persona is too close to your real identity,
The shitty stuff rarely survives the race to the front page so you could probably start by avoiding "/newest". As of Sat, 03 Jan 2026 14:06:17 GMT, there is only one irrelevant item on the front page… and surprisingly little AI, which is quite refreshing.
Strongly recommended.
https://cityofdarkness.co.uk/
reply