8 ms·

Terminals should generate the 256-color palette

495 points by tosh 9mo ago

King-Aaron 9mo ago
> Complex and color-heavy programs struggle with such a small palette. Damn if only there was some other system that could be operating with that in mind
- worthless-trash 9mo ago
  I feel like you're saying one operating system does it better, but I fail to think of one.
  - gzread 9mo ago
    Windows allows you to set any pixel to any 24-bit colour.
    - OJFord 9mo ago
      Not really an OS thing, you can get 24 bit 'true' colour on Linux/macOS too depending on term. Alacritty supports it, for example.
      - gzread 9mo ago
        You need support from third party software such as Xorg or Weston. On Windows, it just works.
        cap11235 9mo ago
        Do you think xorg and weston dont support more than 16 colors? You just run a different terminal emulator.
        gzread 9mo ago
        So I need a terminal emulator to see colours? On Windows I just open a window and put colours in it.
        iamnothere 9mo ago
        Windows doesn’t even have a framebuffer console, so you’re not exactly comparing apples to apples here. In a Linux GUI (X or Wayland) running a modern terminal you get what you are asking for. Same as Windows except that standard Windows lacks the ability to run without a GUI.
        OJFord 9mo ago
        That's ridiculous, even if you extend third-party to mean 'not bundled', with Linux depending on distro that's just everything except the kernel anyway, it's not some 'oh my god it's not bundled it doesn't just work', that's exactly the way it does work - if you want something you install it. (And if you don't make such an extension, what, you have no third-party graphics drivers for example?)
        worthless-trash 9mo ago
        I believe these are 'first party' software when it comes to linux.
      - worthless-trash 9mo ago
        Apples shipping terminal is drastically featureless in comparison to a lot of third party terminals.
  - King-Aaron 9mo ago
    Eh, i was being facetious, but really the point being it's kind of beyond the scope of what a terminal is for if we start plugging in full colour rendering. It is still cool.
jimrandomh 9mo ago
Yeah, when you point it out, this makes complete sense and every terminal should probably add this feature. I think I would generalize this to 24-bit color as well; 16 colors isn't enough to identify a unique tonemap, but if you fiddle with the parameters a bit I think it shouldn't be too hard to come up with something hacky that works. 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.
- Sardtok 9mo ago
  Interesting. You could build a LUT from the 16 color palette to map the 24 bit color space to something 24 bits or less. A bit like mapping 10 bit HDR to 24 bit sRGB. 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.
aragilar 9mo ago
This definitely seems like a sensible starting option to generate 256 colours from a custom set of 8 (and then let the really pedantic users fiddle with the extended set). I would presume for "standard" themes these values would be pregenerated and adjusted slightly if needed.
johncoltrane 9mo ago
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.
- jauntywundrkind 9mo ago
  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.
  - johncoltrane 9mo ago
    I have a bunch of Vim colorschemes under my belt. 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.
dwb 9mo ago
Agree, and I love how concise, yet persuasive and practical this proposal is.
deleted 9mo ago
[deleted]
k3vinw 9mo ago
It’s a messy situation for sure and what lead me to discover tinted theming: https://github.com/tinted-theming/base24/ https://github.com/tinted-theming/base24/ It’s been a fairly decent stop gap measure. I use tinted shell to switch between color schemes.
stackghost 9mo ago
It's perennially baffling to me why we're still clinging to VT220/xterm compatible terminals. I even see people claiming they prefer working in the terminal, though it's not clear to me what type of work those people are doing. 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?
- consp 9mo ago
  Why? There is huge compatibility layer build on top of this and changing even these minor things will break stuff in places you do not expect. Want a fancy terminal? Install another one. By default most allow changing to many terminal formats. Break things to move forward is fun when it's not your problem to solve down the line.
- vanviegen 9mo ago
  GUI apps are good for discoverability. They generally are not optimized for rapid use by power users though. That's of course not an inherent limitation of GUI apps, it's just that dominant paradigms hardly seem to consider power users. 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.
  - robinsonb5 9mo ago
    Another factor is the lack of a good cross-platform GUI toolkit (by which I mean one that (a) doesn't feel out-of-place and jarring on any platform and (b) doesn't turn a 50K app into a 1GB download.) 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.
leni536 9mo ago
What I would like is HDR colors, just to access more saturated light colors. I don't want less saturated blue to make it lighter, just crank up the blue channel to 11. I still don't want brighter colors than #fff though.
- hackrmn 9mo ago
  I think your wish is self-contradicting. `#fff` is so-called _device_ colour -- a device like a LED-based display uses it directly to drive the LEDs, where `#fff` means that the red, the green and the blue channel are already "cranked to 11". The `f` here is equivalent to 11. HDR uses a different color format, I think -- exactly because `#fff` is otherwise either ambigous, or has to map to a different colour gamut -- where, for instance, `#fff` actually means the whitest white cranked up to 11, at however many nits (say 1500) the monitor may emit, which would make your "standard" or "SDR" white (per sRGB, say) that's usually has the emitted strength of around 100 nits, be somewhere at `#888` (I haven't taken into account the _curve_ implied here, at any rate I don't think it's going to be a linear relationship between nits and device primary N-bit colour numbers). 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.
  - account42 9mo ago
    It's pretty obvious that gp is asking for the brightest blue to be as bright as the brightest white but no brighter. 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.
    - 9mo ago
flomo 9mo ago
If any end users actually cared about terminal/TUI apps, there would be modern APIs for whatever they want. Since this is really just a legacy system operator monk / retrocool interface, they spend years debating ancient DEC theology.
- gjvc 9mo ago
  It's a shame to see you get downvoted (presumably because you don't cite any evidence for your assertions). As a counter-point, I will give the oft-quoted-by-me 1990s promotional video of the use of IBM CallPath on an AS/400 which should get you all misty-eyed https://youtu.be/5pY6Xxptp9A?t=2058 https://youtu.be/5pY6Xxptp9A?t=2058 Enjoy.
  - flomo 9mo ago
    IBM = heathen technology. The entire point is fetishization of not that.
    - anthk 9mo ago
      IBM it's a special case. You often have the exact tools under the terminal interface and the GUI 1:1. You can do the same task in the CLI, TUI or with a GUI, now it can perfectly be over a web. But for minimum latency the CLI and TUI are essential and even a 9front user as me I acknowedge that. But 9front it's a special case too; it was basically made to be modular from day one and you can just set a CPU server and connect anything into it over 9p, be physical or not. No SSH needed, everything works the same everywhere.
delaminator 9mo ago
Terminals should not exist, emulating a serial teletype emulating a Hollerith machine
- anthk 9mo ago
  That's 9front/Plan9. No actual terminals, but windows with shells.
  - delaminator 9mo ago
    As you can see from the down votes, people love emulating Hollerith machines. They've probably never tried writing a terminal emulator.
    - xvilka 9mo ago
      As a text interface lover and someone who dived deep into terminal quirks, I do think you have a valid point. We need to design a text interface without all the legacy cruft, better suited for modern needs (including colors), and better mixed-mode output and interaction, something similar to what we have with Jupyter, for example (without the Web/JS/Python baggage though). It would require rebuilding whole ecosystem from scratch though, thus unlikely to happen any time soon.
      - wredcoll 9mo ago
        Oh hey, if only html was text based. Oh, wait, it is. I'm rapidly developing grumpy old man habits about this gulf between "web" and "terminal". Imagine a world where we do `ls | grep .files.size` or something. I mean, I get why we're here, but it feels so close to giving us all the power of html/css/etc while also having pipes and shells.
        worthless-trash 9mo ago
        You know its funny... I had the same point a few days ago: https://news.ycombinator.com/item?id=47005509#47012203 https://news.ycombinator.com/item?id=47005509#47012203 I feel like i'm talking crazy pills, computer still, and always will use blocks of memory, which can be parsed how i see fit. I will die on this hill.
pjmlp 9mo ago
This is a limitation of UNIX terminals, in other platforms not tied to a no longer existing tty interface, this isn't an issue. 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.
- comboy 9mo ago
  I don't know any GUI that beats tmux work portability. 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.
  - anthk 9mo ago
    9front/plan9 leaves tmux and the like as toys. The moment you can use system tools, 9p and files on everything (even the text of the editor itself) you wont be back to these unusable teletype emulators, be XTerm clones or terminal multiplexors.
  - pjmlp 9mo ago
    I know UNIX since being introduced to it via Xenix in 1992 thereabouts, and never found a use for tmux. More so, I use the terminal as strictly necessary and nothing more.
    - wredcoll 9mo ago
      I don't want "a terminal", I want a command based interface combined with being able to use the same set of tools/commands on all the files I interact with. Like, it gets taken for granted, but being able to literally grep my html file, my program source and my readme file, instead of having to open a separate gui program and using its bespoke seach menu feature, is really, really nice. There are downsides of course, like the way we keep jamming everything into the square hole that is 1980s terminal emulators and character based displays, but frequently this is worth it.
      - 9mo ago
amelius 9mo ago
Terminals should be able to show images, so you could run Jupyter notebooks in them.
- Maxious 9mo ago
  Terminals can show images https://sw.kovidgoyal.net/kitty/graphics-protocol/ https://sw.kovidgoyal.net/kitty/graphics-protocol/
  - deleted 9mo ago
    [deleted]
  - amelius 9mo ago
    Ok, maybe I should have said "framebuffers" instead of images. Because that Kitty protocol seems limited in that interaction was not one of their goals.
    - poly2it 9mo ago
      First example on the Kitty image protocol sent above looks pretty interactive: https://github.com/chase/awrit https://github.com/chase/awrit
    - ux266478 9mo ago
      What's the point? If you want a framebuffer, ask the windowing system for one. Why go through a terminal emulator?
      - amelius 9mo ago
        Because this one works through screen/tmux, and works over ssh without messing with DISPLAY variables and such.
- aragilar 9mo ago
  Sixel and ReGIS have been around for decades.
layer8 9mo ago
I’d also add a quantization slider that would quantize the in-between colors to less than 256 different colors; in the extreme position to just the 16 colors.
- ku1ik 9mo ago
  That would be a super-niche setting, but an interesting idea nonetheless.
nubinetwork 9mo ago
Kde has their own palette, and I hate it, the colours are all wrong, and the scheme is fugly... I usually set it to "Linux default" and hope its good enough to read
vanderZwan 9mo ago
Sounds like I should try this together with ametameric, which I've been using since I have protanomaly [0] https://ctx.graphics/terminal/ametameric/ https://ctx.graphics/terminal/ametameric/
tasuki 9mo ago
I had exactly this thought! 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.
- Ferret7446 9mo ago
  The way it's supposed to work is you don't touch the terminal colors but instead configure the program to use different colors. So you don't invert black for a dark theme, instead the program uses white instead of black. By the way, the terminal foreground and background colors are independent of the standard 16 colors, which complicates things.
  - tasuki 9mo ago
    > The way it's supposed to work is you don't touch the terminal colors but instead configure the program to use different colors. That makes sense, but... seems infeasible in practice? "The program"? I tell you what program I need to configure: all of them! Ideally even the programs I'm not even using yet. I think I'll continue doing it my wrong way then: redefining the meanings to mean less/more contrasty. That allows me to effortlessly switch the terminal between light[0] and dark[1] backgrounds. I've done worse things: I also hijacked a part of the 256-colors-cube for my own purposes... [0]: https://github.com/tasuki/dotrc/blob/master/.config/kitty/solar-light.conf https://github.com/tasuki/dotrc/blob/master/.config/kitty/so... [1]: https://github.com/tasuki/dotrc/blob/master/.config/kitty/solar-dark.conf https://github.com/tasuki/dotrc/blob/master/.config/kitty/so...
- skydhash 9mo ago
  Unless you provide a way to configure the colors, it’s better to simply rely on bold, reverse, and standout. If you using the 16p, don’t use black and white unless you know ehat the background is, and use the others sparingly and semantically (no rainbow soup). If you’re going for 256p, it should be in a theme engine that’s user configurable.
therealmarv 9mo ago
seems this is implemented in latest iTerm2 commit https://github.com/gnachman/iTerm2/commit/39bafa8d665186595151872a22659d4a701b00f4 https://github.com/gnachman/iTerm2/commit/39bafa8d6651865951...
iamgrootali 9mo ago
[flagged]
epage 9mo ago
Really interested in this for cargo/rustc. We run into issues where we need one or two more colors but all that is left after going for the basic semantic colors is magenta (odd choice), and black and white (not safe without inspecting the theme).
- skydhash 9mo ago
  Other than red and green, for semantic reasons, a CLI tools shouldn’t bother with colors. And it should support text markers instead of colors for the occasional piping.
  - estebank 9mo ago
    That's what cargo/rustc do: all of the information is conveyed through text, but colors are used to make it easier to scan. It ends up using almost every usable base-16 color: red for the error marker and their primary spans, yellow for warnings and their primary spans, blue for secondary spans, the gutter separator and line numbers, bold text for the main message, cyan for notes and their primary spans, green for helps and their primary spans, green and red for structured suggestions, bright magenta for very specific hand-picked highlights (used to be bold/bright white, but that wasn't obvious enough in lots of terminals, used semantically equivalent to bold or italics in text, the case most people will encounter these in is in E0308 type errors where a specific type parameter didn't match) and white for anything else. Note that of the mentioned output the only thing that is differentiated in color only is the message highlights, and that's because it is generally done for either extra clarification ("Trait is not implemented for Foo, but it is implemented for Bar") or within code that we wouldn't want to pollute with additional non-code ASCII markers (people should be able to copy&paste those types without causing parse errors). Some people deride this variety as being too "christmas tree", but IMO it works quite well for scanning output. Color helps a lot when scanning longer lists and dense output. Colors might not help much if the tool is emitting a single line of output for each event, but rustc emits dozens of lines per error. And no, reducing the amount of output would not be the answer for rustc, you can already use `--message-format=short` if you want that, or try/contribute to one of the TUI projects consuming the json output for dynamic navigation of the output (to expand and contract sections). rustc and cargo default configuration have to cater to the most common case, while also keeping the number of non-essential features (like a built-in TUI) to a minimum.
xvilka 9mo ago
Just use direct color mode (24bit, "true color")[1] and there will be no need for a palette. > Fewer terminals support truecolor. From what I know all modern terminal emulators in all operating systems support it now. [1] https://github.com/termstandard/colors https://github.com/termstandard/colors
- grimgrin 9mo ago
  they explicitly had an opinion about true color, right in the article we’re discussing
- kristopolous 9mo ago
  Doesn't work. You don't have full control over every color all the time and you're going to make assumptions. That's kinda the point.
- globular-toast 9mo ago
  The entire point is to not use true colour but rather a user-configurable theme, but with 256 colours.
- yourapostasy 9mo ago
  We're probably close enough to a future with the technology and engineering able to implement it, to justify designing 48-bit perceptual bit depth standards. Optimistically presuming breakthroughs enabling in vivo biological upgrades to our eyes to match those of mantis shrip, we could design 160-bit standards knowing that is a "proven" biological technology capability. That gets within the same galactic supercluster of the known limits of physics limits. At the currently known limits of physics where Heisenberg Uncertainty Principle, Abbe's Limit, Quantum Shot Noise and such become our sensing barriers, we suspect we need only about 6000 bits per pixel to represent a digital twin of the electromagnetic field of the sensor-covered volume of space. At 60 fps, that is 1.8 Zettabits per second. Scale out data volume accordingly when using using 18.5 sexdecillion fps (Planck time fps). What surprises me is these "limits of the fabric of reality as we know it" mind experiments fairly concretely point the way on the many roads towards Kardashev Scale implementations, and is not that different from Archimedes' "Sand Reckoner" and Hindu cosmological Kalpa time scales. History doesn't quite repeat, but rhymes yet again.
jmbwell 9mo ago
Color schemes voluntarily added by the user to an app like vim, great. 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.
stuaxo 9mo ago
This new palette should be behind a new control code, that should sort out the issue of opting in.
kristopolous 9mo ago
My streaming markdown renderer does something like that https://github.com/day50-dev/Streamdown https://github.com/day50-dev/Streamdown 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#colors-are-highly-and-quickly-configurable-for-people-who-care-a-lot-or-just-a-little https://github.com/day50-dev/Streamdown?tab=readme-ov-file#c... It's effectively a swatch
igneo676 9mo ago
Oddly enough, I'm colorblind and I have had the worst time with color schemes. Many are completely unreadable and lack sufficient contrast. Others I just don't like So, I've started using AI models to generate color schemes for me. Take an unreadable theme I like and generate one that is high contrast and still coherent. It's probably not good enough for a full spectrum vision person to use but wow has it improved my quality of life. It wouldn't surprise me if this is exactly the type of problem that is solved in the same way for the rest of you
- thayne 9mo ago
  > Many are completely unreadable and lack sufficient contrast. I am not colorblind, and have the same experience. It's made worse by the fact that different apps use colors differently, so if I find a theme that works well for some clis and tuis, there will be others that will have unreadably low contrast with the default theme. So I have to tweak the colorscheme for each application as well.
makapuf 9mo ago
We should define a set of base colors for terminal apps that are used for themes so that we have a common set of colors for all term apps. Text, background, borders, hilight, muted then let the terminal set its theme.
evolve2k 9mo ago
A key critique The article is well argued and well written, as far as I’m concerned. What’s needed if you really want adoption is to define a term; something like 256-ex for extended. Or whatever. But folks and apps need to be able to say; we’ve implemented or we support 256-ex. Without this label is hard to drive adoption. The heartbleed thing from a few years back best taught me this. Good luck I hope to see broad adoption it’s a great idea. Give it a name, better yet move the copy onto a website with the same name also and a little icon folks can add to their website if they implement this k to their terminal app.
anthk 9mo ago
Harsh truth for Unix: - A shell is not a terminal. - Rc it's simpler than sh. - You can totally put shells under graphical windows as in 9front - You can do a better Unix than Unix itself while ditching out for good the VT220 interface - Serial terminals aren't a thing under rio(9)
- wang_li 9mo ago
  That's hardly a harsh truth. We use the terminal model because it works good enough and there are decades of software that rely on it. There are certainly other models that could work, but so far they haven't been adopted. I'd love Mathematica style notebooks for my shell work.
  - anthk 9mo ago
    Again, don't confuse the shell (command line interpreter) with a terminal with escape codes and the like. Check how 9font does it, you get the rc shell and a few more languages with a REPL (lua ports and the like) inside a graphical window, not by emulating a VT220 terminal running the shell inside. You can freely resize the 9front's rio window manager's windows running rc (or anything else, even games, graphical browsers, images, video players...), copy, paste, cut the text, save the history, grep the contents of a window's text itself and tons more.
    - wang_li 9mo ago
      You are confusing the unix terminal model with specific terminals. The TTY concept doesn't mandate an 80x24 text only device. Outside of applications that specifically rely upon the existence of a directly addressable grid of characters, Unix TTYs and PTYs would work perfectly fine in a mathematica notebook style interface.
      - anthk 9mo ago
        9front went further; you don't need to care about TTY's and PTY's any more except for the 'vt' tool which was made OFC to connect to Unix terminals and to run some legacy software thru APE/NPE (minimal POSIX compat modules). The core concept of Unix weren't the terminals, but text, pipes and the orthogonal composability. rc under 9front doesn't need a terminal emulating some DEC hardware crudely. You get a shell not bound to sizes. Scripts run in the same way, but with superior editing capabilities.
Andrex 9mo ago
Wild, potentially stupid thought: why couldn't a terminal let users supply a user.css like browsers? They'd only have to support the small subset of text styles.
- skydhash 9mo ago
  Color 0 to 15 are user-customizable by all terminals I know of. Color 16 to 255 are standardized, and the same across all terminals. Most (good?) cli and TUI use the first sets, while any that uses the second set usually are used through a theme engine (per app customization though).
urmane 9mo ago
I see TFA mentions Solarized. I've been using Solarized light for longer than I can remember, even on Windows where I can (eg VSCode), and it goes a long way to making my eyes happy. I share the irritation with dark blue on black and can't stand dark mode (maybe I'm now old and no longer 31337 ... alas ...) For my ncurses brothers, saw this but have not used yet: https://github.com/dankamongmen/notcurses https://github.com/dankamongmen/notcurses For my plan9 brothers: one day we will have a new acme, written in common lisp and displaying all the correct colors, and lo it will be glorious.
DiabloD3 9mo ago
And this is why we have the Tc extension that terminals must implement now: I just use the 24 bit value I want directly.
- thayne 9mo ago
  The OP specifically says why that isn't ideal: The mainstream solution is to use truecolor and gain access to 16 million colors. But there are drawbacks: Each truecolor program needs its own theme configuration. Changing your color scheme means editing multiple config files. Light/dark switching requires explicit support from program maintainers. Truecolor escape codes are longer and slower to parse. Fewer terminals support truecolor.
  - DiabloD3 9mo ago
    > Each truecolor program needs its own theme configuration. Yes, but programs that need more than 16 colors are already often doing this. > Changing your color scheme means editing multiple config files. Already has been implemented at least several times over. > Light/dark switching requires explicit support from program maintainers. Yes, we have an escape sequence to ask the terminal to ask the OS for this. Most programs that need to care about this already use it. > Truecolor escape codes are longer and slower to parse. Not in a way that matters. It only shows up on torture test benchmarks on especially slow parsers. It wouldn't effect normal usage even on a terminal running on some tiny SBC. > Fewer terminals support truecolor. XTerm itself, rxvt, iterm2, Alacritty, Wez, Kitty, Ghostty, wt/modern conhost, mintty, st, everything that uses libvte, everything that uses libvterm (such as neovim's built in term), emacs's term, asciinema; tmux, screen, dvtm safely handle them; the linux console snaps it to the nearest 256 color; iterm.app, the original garbage osx one, is the only major term I can think of that does not handle it.
linhns 9mo ago
Nice to see Ghostty implemented it already. Feature-packed with sane defaults.
eqvinox 9mo ago
The problem with this change is that it breaks setups for people who have already adjusted their color schemes to work with the 256-color palette as it is. It's now essentially double-adjusted. (…and people wonder why I use gvim rather than vim…)
foldr 9mo ago
> If you've spent much time in the terminal, you've probably set a custom base16 theme. Hmm, I suspect that almost everyone who works in the terminal has never done this. I don’t really care what the colors look like, beyond choosing between whatever built in themes my terminal has. Is this really the minority experience?
- kccqzy 9mo ago
  I'm pretty sure the word "custom" refers to the act of choosing among builtin themes in the terminal. Some terminals like ghostty have hundreds builtin.
cyanbane 9mo ago
Should call it Super Terminal Entertainment System.
rbanffy 9mo ago
I’m concerned not everyone have their base colors set sensibly - as in “there’s no guarantee the base garish RGB green is green on this machine”. Maybe the right thing would be to put the color closest to a base color on the corresponding corner of the RGB cube, but that’s also not ideal - I have had terminal palettes that were all green or all orange/red, or the green/yellow of EL displays. Maybe applying the saturation of the base set across all the generated palette would also work.
kccqzy 9mo ago
The word “should” is way too strong. It’s ultimately just a personal preference. For me I would prefer a two-tier approach. There are different programs inside the terminal that I would prefer to have different color treatment. A full-fledged editor like emacs should have full 24-bit color support because I have already configured it to have my preferred color schemes and I prefer to switch themes inside emacs. On the other hand, almost all other TUI programs should not be permitted to use more than the traditional 16 colors. I haven’t configured them myself so I don’t trust them to make good choices. In other words different terminal capabilities for different programs.

495 points by tosh 9mo ago

> Complex and color-heavy programs struggle with such a small palette. Damn if only there was some other system that could be operating with that in mind

worthless-trash 9mo ago
I feel like you're saying one operating system does it better, but I fail to think of one.
- gzread 9mo ago
  Windows allows you to set any pixel to any 24-bit colour.
  - OJFord 9mo ago
    Not really an OS thing, you can get 24 bit 'true' colour on Linux/macOS too depending on term. Alacritty supports it, for example.
    - gzread 9mo ago
      You need support from third party software such as Xorg or Weston. On Windows, it just works.
      - cap11235 9mo ago
        Do you think xorg and weston dont support more than 16 colors? You just run a different terminal emulator.
        gzread 9mo ago
        So I need a terminal emulator to see colours? On Windows I just open a window and put colours in it.
        iamnothere 9mo ago
        Windows doesn’t even have a framebuffer console, so you’re not exactly comparing apples to apples here. In a Linux GUI (X or Wayland) running a modern terminal you get what you are asking for. Same as Windows except that standard Windows lacks the ability to run without a GUI.
      - OJFord 9mo ago
        That's ridiculous, even if you extend third-party to mean 'not bundled', with Linux depending on distro that's just everything except the kernel anyway, it's not some 'oh my god it's not bundled it doesn't just work', that's exactly the way it does work - if you want something you install it. (And if you don't make such an extension, what, you have no third-party graphics drivers for example?)
      - worthless-trash 9mo ago
        I believe these are 'first party' software when it comes to linux.
    - worthless-trash 9mo ago
      Apples shipping terminal is drastically featureless in comparison to a lot of third party terminals.
- King-Aaron 9mo ago
  Eh, i was being facetious, but really the point being it's kind of beyond the scope of what a terminal is for if we start plugging in full colour rendering. It is still cool.

jimrandomh 9mo ago

Yeah, when you point it out, this makes complete sense and every terminal should probably add this feature. I think I would generalize this to 24-bit color as well; 16 colors isn't enough to identify a unique tonemap, but if you fiddle with the parameters a bit I think it shouldn't be too hard to come up with something hacky that works. 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.

Sardtok 9mo ago
Interesting. You could build a LUT from the 16 color palette to map the 24 bit color space to something 24 bits or less. A bit like mapping 10 bit HDR to 24 bit sRGB. 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.

aragilar 9mo ago

This definitely seems like a sensible starting option to generate 256 colours from a custom set of 8 (and then let the really pedantic users fiddle with the extended set). I would presume for "standard" themes these values would be pregenerated and adjusted slightly if needed.

johncoltrane 9mo ago

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.

jauntywundrkind 9mo ago
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.
- johncoltrane 9mo ago
  I have a bunch of Vim colorschemes under my belt. 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.

dwb 9mo ago

Agree, and I love how concise, yet persuasive and practical this proposal is.

deleted 9mo ago

[deleted]

k3vinw 9mo ago

It’s a messy situation for sure and what lead me to discover tinted theming: https://github.com/tinted-theming/base24/ https://github.com/tinted-theming/base24/ It’s been a fairly decent stop gap measure. I use tinted shell to switch between color schemes.

stackghost 9mo ago

It's perennially baffling to me why we're still clinging to VT220/xterm compatible terminals. I even see people claiming they prefer working in the terminal, though it's not clear to me what type of work those people are doing. 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?

consp 9mo ago
Why? There is huge compatibility layer build on top of this and changing even these minor things will break stuff in places you do not expect. Want a fancy terminal? Install another one. By default most allow changing to many terminal formats. Break things to move forward is fun when it's not your problem to solve down the line.
vanviegen 9mo ago
GUI apps are good for discoverability. They generally are not optimized for rapid use by power users though. That's of course not an inherent limitation of GUI apps, it's just that dominant paradigms hardly seem to consider power users. 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.
- robinsonb5 9mo ago
  Another factor is the lack of a good cross-platform GUI toolkit (by which I mean one that (a) doesn't feel out-of-place and jarring on any platform and (b) doesn't turn a 50K app into a 1GB download.) 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.

leni536 9mo ago

What I would like is HDR colors, just to access more saturated light colors. I don't want less saturated blue to make it lighter, just crank up the blue channel to 11. I still don't want brighter colors than #fff though.

hackrmn 9mo ago
I think your wish is self-contradicting. `#fff` is so-called _device_ colour -- a device like a LED-based display uses it directly to drive the LEDs, where `#fff` means that the red, the green and the blue channel are already "cranked to 11". The `f` here is equivalent to 11. HDR uses a different color format, I think -- exactly because `#fff` is otherwise either ambigous, or has to map to a different colour gamut -- where, for instance, `#fff` actually means the whitest white cranked up to 11, at however many nits (say 1500) the monitor may emit, which would make your "standard" or "SDR" white (per sRGB, say) that's usually has the emitted strength of around 100 nits, be somewhere at `#888` (I haven't taken into account the _curve_ implied here, at any rate I don't think it's going to be a linear relationship between nits and device primary N-bit colour numbers). 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.
- account42 9mo ago
  It's pretty obvious that gp is asking for the brightest blue to be as bright as the brightest white but no brighter. 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.
  - 9mo ago

flomo 9mo ago

If any end users actually cared about terminal/TUI apps, there would be modern APIs for whatever they want. Since this is really just a legacy system operator monk / retrocool interface, they spend years debating ancient DEC theology.

gjvc 9mo ago
It's a shame to see you get downvoted (presumably because you don't cite any evidence for your assertions). As a counter-point, I will give the oft-quoted-by-me 1990s promotional video of the use of IBM CallPath on an AS/400 which should get you all misty-eyed https://youtu.be/5pY6Xxptp9A?t=2058 https://youtu.be/5pY6Xxptp9A?t=2058 Enjoy.
- flomo 9mo ago
  IBM = heathen technology. The entire point is fetishization of not that.
  - anthk 9mo ago
    IBM it's a special case. You often have the exact tools under the terminal interface and the GUI 1:1. You can do the same task in the CLI, TUI or with a GUI, now it can perfectly be over a web. But for minimum latency the CLI and TUI are essential and even a 9front user as me I acknowedge that. But 9front it's a special case too; it was basically made to be modular from day one and you can just set a CPU server and connect anything into it over 9p, be physical or not. No SSH needed, everything works the same everywhere.

delaminator 9mo ago

Terminals should not exist, emulating a serial teletype emulating a Hollerith machine

anthk 9mo ago
That's 9front/Plan9. No actual terminals, but windows with shells.
- delaminator 9mo ago
  As you can see from the down votes, people love emulating Hollerith machines. They've probably never tried writing a terminal emulator.
  - xvilka 9mo ago
    As a text interface lover and someone who dived deep into terminal quirks, I do think you have a valid point. We need to design a text interface without all the legacy cruft, better suited for modern needs (including colors), and better mixed-mode output and interaction, something similar to what we have with Jupyter, for example (without the Web/JS/Python baggage though). It would require rebuilding whole ecosystem from scratch though, thus unlikely to happen any time soon.
    - wredcoll 9mo ago
      Oh hey, if only html was text based. Oh, wait, it is. I'm rapidly developing grumpy old man habits about this gulf between "web" and "terminal". Imagine a world where we do `ls | grep .files.size` or something. I mean, I get why we're here, but it feels so close to giving us all the power of html/css/etc while also having pipes and shells.
      - worthless-trash 9mo ago
        You know its funny... I had the same point a few days ago: https://news.ycombinator.com/item?id=47005509#47012203 https://news.ycombinator.com/item?id=47005509#47012203 I feel like i'm talking crazy pills, computer still, and always will use blocks of memory, which can be parsed how i see fit. I will die on this hill.

pjmlp 9mo ago

This is a limitation of UNIX terminals, in other platforms not tied to a no longer existing tty interface, this isn't an issue. 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.

comboy 9mo ago
I don't know any GUI that beats tmux work portability. 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.
- anthk 9mo ago
  9front/plan9 leaves tmux and the like as toys. The moment you can use system tools, 9p and files on everything (even the text of the editor itself) you wont be back to these unusable teletype emulators, be XTerm clones or terminal multiplexors.
- pjmlp 9mo ago
  I know UNIX since being introduced to it via Xenix in 1992 thereabouts, and never found a use for tmux. More so, I use the terminal as strictly necessary and nothing more.
  - wredcoll 9mo ago
    I don't want "a terminal", I want a command based interface combined with being able to use the same set of tools/commands on all the files I interact with. Like, it gets taken for granted, but being able to literally grep my html file, my program source and my readme file, instead of having to open a separate gui program and using its bespoke seach menu feature, is really, really nice. There are downsides of course, like the way we keep jamming everything into the square hole that is 1980s terminal emulators and character based displays, but frequently this is worth it.
    - 9mo ago

amelius 9mo ago

Terminals should be able to show images, so you could run Jupyter notebooks in them.

Maxious 9mo ago
Terminals can show images https://sw.kovidgoyal.net/kitty/graphics-protocol/ https://sw.kovidgoyal.net/kitty/graphics-protocol/
- deleted 9mo ago
  [deleted]
- amelius 9mo ago
  Ok, maybe I should have said "framebuffers" instead of images. Because that Kitty protocol seems limited in that interaction was not one of their goals.
  - poly2it 9mo ago
    First example on the Kitty image protocol sent above looks pretty interactive: https://github.com/chase/awrit https://github.com/chase/awrit
  - ux266478 9mo ago
    What's the point? If you want a framebuffer, ask the windowing system for one. Why go through a terminal emulator?
    - amelius 9mo ago
      Because this one works through screen/tmux, and works over ssh without messing with DISPLAY variables and such.
aragilar 9mo ago
Sixel and ReGIS have been around for decades.

layer8 9mo ago

I’d also add a quantization slider that would quantize the in-between colors to less than 256 different colors; in the extreme position to just the 16 colors.

ku1ik 9mo ago
That would be a super-niche setting, but an interesting idea nonetheless.

nubinetwork 9mo ago

Kde has their own palette, and I hate it, the colours are all wrong, and the scheme is fugly... I usually set it to "Linux default" and hope its good enough to read

vanderZwan 9mo ago

Sounds like I should try this together with ametameric, which I've been using since I have protanomaly [0] https://ctx.graphics/terminal/ametameric/ https://ctx.graphics/terminal/ametameric/

tasuki 9mo ago

I had exactly this thought! 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.

Ferret7446 9mo ago
The way it's supposed to work is you don't touch the terminal colors but instead configure the program to use different colors. So you don't invert black for a dark theme, instead the program uses white instead of black. By the way, the terminal foreground and background colors are independent of the standard 16 colors, which complicates things.
- tasuki 9mo ago
  > The way it's supposed to work is you don't touch the terminal colors but instead configure the program to use different colors. That makes sense, but... seems infeasible in practice? "The program"? I tell you what program I need to configure: all of them! Ideally even the programs I'm not even using yet. I think I'll continue doing it my wrong way then: redefining the meanings to mean less/more contrasty. That allows me to effortlessly switch the terminal between light[0] and dark[1] backgrounds. I've done worse things: I also hijacked a part of the 256-colors-cube for my own purposes... [0]: https://github.com/tasuki/dotrc/blob/master/.config/kitty/solar-light.conf https://github.com/tasuki/dotrc/blob/master/.config/kitty/so... [1]: https://github.com/tasuki/dotrc/blob/master/.config/kitty/solar-dark.conf https://github.com/tasuki/dotrc/blob/master/.config/kitty/so...
skydhash 9mo ago
Unless you provide a way to configure the colors, it’s better to simply rely on bold, reverse, and standout. If you using the 16p, don’t use black and white unless you know ehat the background is, and use the others sparingly and semantically (no rainbow soup). If you’re going for 256p, it should be in a theme engine that’s user configurable.

therealmarv 9mo ago

seems this is implemented in latest iTerm2 commit https://github.com/gnachman/iTerm2/commit/39bafa8d665186595151872a22659d4a701b00f4 https://github.com/gnachman/iTerm2/commit/39bafa8d6651865951...

iamgrootali 9mo ago

[flagged]

epage 9mo ago

Really interested in this for cargo/rustc. We run into issues where we need one or two more colors but all that is left after going for the basic semantic colors is magenta (odd choice), and black and white (not safe without inspecting the theme).

skydhash 9mo ago
Other than red and green, for semantic reasons, a CLI tools shouldn’t bother with colors. And it should support text markers instead of colors for the occasional piping.
- estebank 9mo ago
  That's what cargo/rustc do: all of the information is conveyed through text, but colors are used to make it easier to scan. It ends up using almost every usable base-16 color: red for the error marker and their primary spans, yellow for warnings and their primary spans, blue for secondary spans, the gutter separator and line numbers, bold text for the main message, cyan for notes and their primary spans, green for helps and their primary spans, green and red for structured suggestions, bright magenta for very specific hand-picked highlights (used to be bold/bright white, but that wasn't obvious enough in lots of terminals, used semantically equivalent to bold or italics in text, the case most people will encounter these in is in E0308 type errors where a specific type parameter didn't match) and white for anything else. Note that of the mentioned output the only thing that is differentiated in color only is the message highlights, and that's because it is generally done for either extra clarification ("Trait is not implemented for Foo, but it is implemented for Bar") or within code that we wouldn't want to pollute with additional non-code ASCII markers (people should be able to copy&paste those types without causing parse errors). Some people deride this variety as being too "christmas tree", but IMO it works quite well for scanning output. Color helps a lot when scanning longer lists and dense output. Colors might not help much if the tool is emitting a single line of output for each event, but rustc emits dozens of lines per error. And no, reducing the amount of output would not be the answer for rustc, you can already use `--message-format=short` if you want that, or try/contribute to one of the TUI projects consuming the json output for dynamic navigation of the output (to expand and contract sections). rustc and cargo default configuration have to cater to the most common case, while also keeping the number of non-essential features (like a built-in TUI) to a minimum.

xvilka 9mo ago

Just use direct color mode (24bit, "true color")[1] and there will be no need for a palette. > Fewer terminals support truecolor. From what I know all modern terminal emulators in all operating systems support it now. [1] https://github.com/termstandard/colors https://github.com/termstandard/colors

grimgrin 9mo ago
they explicitly had an opinion about true color, right in the article we’re discussing
kristopolous 9mo ago
Doesn't work. You don't have full control over every color all the time and you're going to make assumptions. That's kinda the point.
globular-toast 9mo ago
The entire point is to not use true colour but rather a user-configurable theme, but with 256 colours.
yourapostasy 9mo ago
We're probably close enough to a future with the technology and engineering able to implement it, to justify designing 48-bit perceptual bit depth standards. Optimistically presuming breakthroughs enabling in vivo biological upgrades to our eyes to match those of mantis shrip, we could design 160-bit standards knowing that is a "proven" biological technology capability. That gets within the same galactic supercluster of the known limits of physics limits. At the currently known limits of physics where Heisenberg Uncertainty Principle, Abbe's Limit, Quantum Shot Noise and such become our sensing barriers, we suspect we need only about 6000 bits per pixel to represent a digital twin of the electromagnetic field of the sensor-covered volume of space. At 60 fps, that is 1.8 Zettabits per second. Scale out data volume accordingly when using using 18.5 sexdecillion fps (Planck time fps). What surprises me is these "limits of the fabric of reality as we know it" mind experiments fairly concretely point the way on the many roads towards Kardashev Scale implementations, and is not that different from Archimedes' "Sand Reckoner" and Hindu cosmological Kalpa time scales. History doesn't quite repeat, but rhymes yet again.

jmbwell 9mo ago

Color schemes voluntarily added by the user to an app like vim, great. 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.

stuaxo 9mo ago

This new palette should be behind a new control code, that should sort out the issue of opting in.

kristopolous 9mo ago

My streaming markdown renderer does something like that https://github.com/day50-dev/Streamdown https://github.com/day50-dev/Streamdown 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#colors-are-highly-and-quickly-configurable-for-people-who-care-a-lot-or-just-a-little https://github.com/day50-dev/Streamdown?tab=readme-ov-file#c... It's effectively a swatch

igneo676 9mo ago

Oddly enough, I'm colorblind and I have had the worst time with color schemes. Many are completely unreadable and lack sufficient contrast. Others I just don't like So, I've started using AI models to generate color schemes for me. Take an unreadable theme I like and generate one that is high contrast and still coherent. It's probably not good enough for a full spectrum vision person to use but wow has it improved my quality of life. It wouldn't surprise me if this is exactly the type of problem that is solved in the same way for the rest of you

thayne 9mo ago
> Many are completely unreadable and lack sufficient contrast. I am not colorblind, and have the same experience. It's made worse by the fact that different apps use colors differently, so if I find a theme that works well for some clis and tuis, there will be others that will have unreadably low contrast with the default theme. So I have to tweak the colorscheme for each application as well.

makapuf 9mo ago

We should define a set of base colors for terminal apps that are used for themes so that we have a common set of colors for all term apps. Text, background, borders, hilight, muted then let the terminal set its theme.

evolve2k 9mo ago

A key critique The article is well argued and well written, as far as I’m concerned. What’s needed if you really want adoption is to define a term; something like 256-ex for extended. Or whatever. But folks and apps need to be able to say; we’ve implemented or we support 256-ex. Without this label is hard to drive adoption. The heartbleed thing from a few years back best taught me this. Good luck I hope to see broad adoption it’s a great idea. Give it a name, better yet move the copy onto a website with the same name also and a little icon folks can add to their website if they implement this k to their terminal app.

anthk 9mo ago

Harsh truth for Unix: - A shell is not a terminal. - Rc it's simpler than sh. - You can totally put shells under graphical windows as in 9front - You can do a better Unix than Unix itself while ditching out for good the VT220 interface - Serial terminals aren't a thing under rio(9)

wang_li 9mo ago
That's hardly a harsh truth. We use the terminal model because it works good enough and there are decades of software that rely on it. There are certainly other models that could work, but so far they haven't been adopted. I'd love Mathematica style notebooks for my shell work.
- anthk 9mo ago
  Again, don't confuse the shell (command line interpreter) with a terminal with escape codes and the like. Check how 9font does it, you get the rc shell and a few more languages with a REPL (lua ports and the like) inside a graphical window, not by emulating a VT220 terminal running the shell inside. You can freely resize the 9front's rio window manager's windows running rc (or anything else, even games, graphical browsers, images, video players...), copy, paste, cut the text, save the history, grep the contents of a window's text itself and tons more.
  - wang_li 9mo ago
    You are confusing the unix terminal model with specific terminals. The TTY concept doesn't mandate an 80x24 text only device. Outside of applications that specifically rely upon the existence of a directly addressable grid of characters, Unix TTYs and PTYs would work perfectly fine in a mathematica notebook style interface.
    - anthk 9mo ago
      9front went further; you don't need to care about TTY's and PTY's any more except for the 'vt' tool which was made OFC to connect to Unix terminals and to run some legacy software thru APE/NPE (minimal POSIX compat modules). The core concept of Unix weren't the terminals, but text, pipes and the orthogonal composability. rc under 9front doesn't need a terminal emulating some DEC hardware crudely. You get a shell not bound to sizes. Scripts run in the same way, but with superior editing capabilities.

Andrex 9mo ago

Wild, potentially stupid thought: why couldn't a terminal let users supply a user.css like browsers? They'd only have to support the small subset of text styles.

skydhash 9mo ago
Color 0 to 15 are user-customizable by all terminals I know of. Color 16 to 255 are standardized, and the same across all terminals. Most (good?) cli and TUI use the first sets, while any that uses the second set usually are used through a theme engine (per app customization though).

urmane 9mo ago

I see TFA mentions Solarized. I've been using Solarized light for longer than I can remember, even on Windows where I can (eg VSCode), and it goes a long way to making my eyes happy. I share the irritation with dark blue on black and can't stand dark mode (maybe I'm now old and no longer 31337 ... alas ...) For my ncurses brothers, saw this but have not used yet: https://github.com/dankamongmen/notcurses https://github.com/dankamongmen/notcurses For my plan9 brothers: one day we will have a new acme, written in common lisp and displaying all the correct colors, and lo it will be glorious.

DiabloD3 9mo ago

And this is why we have the Tc extension that terminals must implement now: I just use the 24 bit value I want directly.

thayne 9mo ago
The OP specifically says why that isn't ideal: The mainstream solution is to use truecolor and gain access to 16 million colors. But there are drawbacks: Each truecolor program needs its own theme configuration. Changing your color scheme means editing multiple config files. Light/dark switching requires explicit support from program maintainers. Truecolor escape codes are longer and slower to parse. Fewer terminals support truecolor.
- DiabloD3 9mo ago
  > Each truecolor program needs its own theme configuration. Yes, but programs that need more than 16 colors are already often doing this. > Changing your color scheme means editing multiple config files. Already has been implemented at least several times over. > Light/dark switching requires explicit support from program maintainers. Yes, we have an escape sequence to ask the terminal to ask the OS for this. Most programs that need to care about this already use it. > Truecolor escape codes are longer and slower to parse. Not in a way that matters. It only shows up on torture test benchmarks on especially slow parsers. It wouldn't effect normal usage even on a terminal running on some tiny SBC. > Fewer terminals support truecolor. XTerm itself, rxvt, iterm2, Alacritty, Wez, Kitty, Ghostty, wt/modern conhost, mintty, st, everything that uses libvte, everything that uses libvterm (such as neovim's built in term), emacs's term, asciinema; tmux, screen, dvtm safely handle them; the linux console snaps it to the nearest 256 color; iterm.app, the original garbage osx one, is the only major term I can think of that does not handle it.

linhns 9mo ago

Nice to see Ghostty implemented it already. Feature-packed with sane defaults.

eqvinox 9mo ago

The problem with this change is that it breaks setups for people who have already adjusted their color schemes to work with the 256-color palette as it is. It's now essentially double-adjusted. (…and people wonder why I use gvim rather than vim…)

foldr 9mo ago

> If you've spent much time in the terminal, you've probably set a custom base16 theme. Hmm, I suspect that almost everyone who works in the terminal has never done this. I don’t really care what the colors look like, beyond choosing between whatever built in themes my terminal has. Is this really the minority experience?

kccqzy 9mo ago
I'm pretty sure the word "custom" refers to the act of choosing among builtin themes in the terminal. Some terminals like ghostty have hundreds builtin.

cyanbane 9mo ago

Should call it Super Terminal Entertainment System.

rbanffy 9mo ago

I’m concerned not everyone have their base colors set sensibly - as in “there’s no guarantee the base garish RGB green is green on this machine”. Maybe the right thing would be to put the color closest to a base color on the corresponding corner of the RGB cube, but that’s also not ideal - I have had terminal palettes that were all green or all orange/red, or the green/yellow of EL displays. Maybe applying the saturation of the base set across all the generated palette would also work.

kccqzy 9mo ago

The word “should” is way too strong. It’s ultimately just a personal preference. For me I would prefer a two-tier approach. There are different programs inside the terminal that I would prefer to have different color treatment. A full-fledged editor like emacs should have full 24-bit color support because I have already configured it to have my preferred color schemes and I prefer to switch themes inside emacs. On the other hand, almost all other TUI programs should not be permitted to use more than the traditional 16 colors. I haven’t configured them myself so I don’t trust them to make good choices. In other words different terminal capabilities for different programs.