Live data from Hacker News

Terminals should generate the 256-color palette

gist.github.com

111–120 of 212 posts

Re: Terminals should generate the 256-color palette

#111
post #37
post #33

Earlier quoted context omitted.

Terminals can show images https://sw.kovidgoyal.net/kitty/graphics-protocol/

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.

What's the point? If you want a framebuffer, ask the windowing system for one. Why go through a terminal emulator?

Re: Terminals should generate the 256-color palette

#113
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

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.

Re: Terminals should generate the 256-color palette

#114
post #103

Earlier quoted context omitted.

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 fo…

Running a software project means making choices. Currently, the choice is made to make blue text unreadable. That's not a great choice, in my opinion.

Re: Terminals should generate the 256-color palette

#115

Earlier quoted context omitted.

No one can and people have been complaining about it for decades. But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation. And no urgency either, because all terminal emulators allow users to customize the palette anyway.

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.

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

Re: Terminals should generate the 256-color palette

#116
post #73

Earlier quoted context omitted.

Do you think xorg and weston dont support more than 16 colors? You just run a different terminal emulator.

So I need a terminal emulator to see colours? On Windows I just open a window and put colours in it.

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.

Re: Terminals should generate the 256-color palette

#117

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 t…

> This is very useful for colorscheme developers

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).

Re: Terminals should generate the 256-color palette

#118
post #48

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 t…

> provide a [...] consistent experience 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.

I thought we had left TUIs behind in the 90's, instead it is rainbowns, unicorns, and whatever else going with those stylisic experiences.

Re: Terminals should generate the 256-color palette

#119
post #56

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

That's 9front/Plan9. No actual terminals, but windows with shells.

As you can see from the down votes, people love emulating Hollerith machines. They've probably never tried writing a terminal emulator.

Re: Terminals should generate the 256-color palette

#120
post #64

Earlier quoted context omitted.

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. XKCD 1172? https://xkcd.com/1172/

It has been working for decades and I would rather have it keep working for decades to come. What would be optimal is semantic _styles_ (not colors): - The developer marks the string "XXX" as an error message without even trying to style it. - The platform/user agent/terminal/whatever displays the string in the default style for "error". - The user can adjust the theme of their platform/user agent/terminal/whatever t…

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.
Post reply on HN