Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terminals should generate the 256-color palette

gist.github.com

Post reply on HN
Print view View original

61–70 of 212 posts

Re: Terminals should generate the 256-color palette

#61

Post by tasuki »

johncoltrane wrote: post #5

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…

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

Re: Terminals should generate the 256-color palette

#62

Post by anthk »

tezza wrote: post #26
stackghost wrote: post #10

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…

Terminals are text. Text adds features missing from gui namely: * 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 com…

Unix is not about a terminal, that the obsolete medium, kinda like preaching about DOS PC with 386's... and CGA video cards.

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.

Re: Terminals should generate the 256-color palette

#63

Post by pjmlp »

comboy wrote: post #39
pjmlp wrote: post #27

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.

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.

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.

Re: Terminals should generate the 256-color palette

#64

Post by poly2it »

johncoltrane wrote: post #59
poly2it wrote: post #54

Earlier quoted context omitted.

Why not truecolor if you want true colours?

I don't want true colours. I want what I already have, 16-255, to stay reliable in the future.

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/

Re: Terminals should generate the 256-color palette

#65

Post by account42 »

hackrmn wrote: post #28
leni536 wrote: post #17

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.

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

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.

Re: Terminals should generate the 256-color palette

#67

Post by heliumtera »

hnlmorg wrote: post #21
johncoltrane wrote: post #5

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…

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

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.

Re: Terminals should generate the 256-color palette

#68

Post by OJFord »

gzread wrote: post #35
OJFord wrote: post #22

Earlier quoted context omitted.

Not really an OS thing, you can get 24 bit 'true' colour on Linux/macOS too depending on term. Alacritty supports it, for example.

You need support from third party software such as Xorg or Weston. On Windows, it just works.

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

Re: Terminals should generate the 256-color palette

#69

Post by Ferret7446 »

tasuki wrote: post #57

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 `b…

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.

Post reply on HN