> Fewer terminals support truecolor.
From what I know all modern terminal emulators in all operating systems support it now.
You define a baseline color in HSV and then everything else is a multiplier of that
For example
[style]
HSV = [0.7, 0.5, 0.5]
Dark = { H = 1.0, S = 1.2, V = 0.25 } # Make dark elements less saturated and darker
Symbol = { H = 1.0, S = 1.8, V = 1.8 } # Make symbols more vibrant
As a result you can simply move around the HSV to your preference in the config and things don't look like garbage where you have to hand tweak every color to get something legible.
For example, this simple loop https://github.com/day50-dev/Streamdown?tab=readme-ov-file#c...
It's effectively a swatch
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.
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.
If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...
An even bigger one is hardcoding black and white instead of using foreground/background and use reverse when needed.
now that react devs finished destroying the web they have to impose their superior taste into terminal through 800mbs TUIs.
Please just don't. This is not the web.
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.
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.
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.
If the user sets a sensible 16 color palette though, many old utils could look great out of the box. I'm enticed by the idea.
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.
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.
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.
XKCD 1172? https://xkcd.com/1172/
Having all terminal emulators run the equivalent of colorcoke without asking the user is not a very bright idea.
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.
Though, I have a problem with even just the basic 16 colours:
black red green yellow blue magenta cyan white bright black bright red bright green bright yellow bright blue bright magenta bright cyan bright white
~~~
Many themes take `black` to mean `black` and `white` to mean `white`. How is it supposed to work when one switches the theme between the dark and the light version?
What are `black`, `white`, `bright black`, and `bright white` supposed mean?
I take those as meaning (in order): `almost invisible on current terminal background`, `pretty contrasty`, `visible but not contrasty`, and `the contrastiest`.
I wish the colour names reflected that, instead of `black` and `white`: you usually care about the contrast, not about the precise colour.
By the way, the terminal foreground and background colors are independent of the standard 16 colors, which complicates things.
All the more reason for developers to keep the app itself responsive to the user’s environment by default.
Don’t bake in elaborate visual choices. It’s a usability thing first and a style thing somewhere much farther down the list.
Keep it simple from the factory. Don’t get in the way of customization. Let the user’s environment do the work of adapting it to the user.
Although, this should probably be optional (both as an option for terminals to have in their own settings, and via an escape sequence that opts out), because some users will have configured some programs with a color scheme that they don't want transformed. For example, if your terminal uses the Solarized color scheme, and your text editor _also_ uses the Solarized color scheme, then this could lead to double-applying a color transform and getting something odd.
Perhaps instead of the application overriding the setting, it could be done with an environment var, so the user can easily override it if the mapping messes with the look/usability of the program.
It’s been a fairly decent stop gap measure. I use tinted shell to switch between color schemes.
Also, `#fff` is ambigous -- if you mean device colour, then there's no brightness (nits) specified at all, it may be 200 or 2000 or 10,000. If sRGB is implied, as in `#fff in sRGB colour space` then the standard specifies 80 nits, so when you say you don't want brighter than that, then you can't have much of HDR since sRGB precludes HDR by definition (can't go brighter than 80 nits for the "whitepoint" aka white).
I think if you want HDR you need a different colour space entirely, which either has a different peak brightness, or one where the brightness is specified additionally to e.g. R, G and B primaries. But here my HDR knowledge is weak -- perhaps someone else may chime in. I just find colour science fascinating, sorry to go on a tangent here.
And no, #fff is not a "device color". The syntax originates from the web where sRGB is implied ever since we had displays brighter than that.
Damn if only there was some other system that could be operating with that in mind
(And if you don't make such an extension, what, you have no third-party graphics drivers for example?)
Give me a proper graphical application any day, but I recognize that it's historically been a lot more work to produce a GUI in the pre-LLM era.
But golly gee whizz if we're going to keep the command line around, can we move on from 1983?
I'm still annoyed and baffled by the fact that Ubuntu had searchable application menus 10 years ago, which were awesome and worked for just about any program, and then dropped them when they abandoned Unity. And neither KDE not Gnome thought to bring them back. In stead, many apps have since dropped application menus entirely, in favour of... some mishmash of icons and ad hoc menu buttons?
Also, even in the post-LLM era, building a decent GUI app is a lot more work than building a decent terminal app.
Between that and the level of complexity of modern GUI toolkits - and the size of their dependency trees - distribution of a GUI app is a much bigger headache than distributing a terminal app.
Super easy to use, fast, almost zero ram usage and battle tested for 2 decades.
* Ad Hoc
requirements change and terminal gives ultimate empty workbench flexibility. awesome for tasks you never new you had until that moment.
* Precision
run precisely what you want, when you want it. you are not constrained by gui UX limits.
* Pipeline
cat file.txt | perl/awk/sed/jq | tee output.result
* Equal Status
everything is text so you can combine clipboard, files, netcat output, curl output and then you can transform (above) and save. whatever you like in whatever form you like, named whatever you like.
9front copes with actual text throwing the terminal as a different tool to run legacy stuff in such as SSH or some small ANSI C tools either with the APE compat layer or NPE binding ANSI C code to Plan9 native functins.
You can resize windows with shells under 9front freely, no more SIGWINCH. No more broken cuts and pastes while running a terminal multiplexer. No control code risks executing potential malware.
My typical interface is that I have an editor open where I write package code, and then I have a julia REPL open beside it where I load the package (or includet the script or testset). Any changes I make with my editor to functions or structs in the package / script / testset are automatically reflected in my running julia session via Revise.jl.
I then execute the functions interactively from the REPL, introspect into data or generated code, debug, run benchmarks etc all from the REPL.
GUIs are great for many things, but they lack the flexibility I need for my day to day work.
Think of it like different types of programming languages. Some are more suited on different types of problems than others.
For me, my workflow is about composing and gluing different processes together rather than using a standard defined tool repeatedly in the same way as that tools UI was originally designed. So the CLI is ideally suited for me in all the areas where a GUI would be high friction.
As little as possible. Anything that can be done in a terminal can be scripted and automated, put under version control, and deployed using modern CI/CD and devops tools.
Sure, next time I'll need to quickly edit a configuration file I'll setup a complete CI/CD pipeline to run vim (or nano, or whatever) inside it.
Because that Kitty protocol seems limited in that interaction was not one of their goals.
Since this is really just a legacy system operator monk / retrocool interface, they spend years debating ancient DEC theology.
Enjoy.
Unfortunely, given that we are stuck with UNIX derived OSes, this is indeed a possible issue.
However I would argue, for fancy stuff there is the GUI right there.
Of course everything depends on exact nature of the work, but personally I would gladly leave text based interfaces behind, it's just that there's nothing better.
More so, I use the terminal as strictly necessary and nothing more.