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

41–50 of 212 posts

Re: Terminals should generate the 256-color palette

#41

Post by eigenspace »

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…

Personally, I find a REPL-based programming interface to be the most flexible and powerful way to interact with code.

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.

Re: Terminals should generate the 256-color palette

#43

Post by iberator »

robinsonb5 wrote: post #25
vanviegen wrote: post #13

Earlier quoted context omitted.

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

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.

there is TCL-TK. :)

Super easy to use, fast, almost zero ram usage and battle tested for 2 decades.

Re: Terminals should generate the 256-color palette

#45

Post by vova_hn2 »

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'm sorry, but I find this mentality from app developers extremely annoying.

I personally prefer light themes everywhere, both in IDEs and in the terminal. I thought that just choosing my own color scheme for 0-15 would give me the color pallette that I prefer, but because app developers like you for some reason decided that you know better what colors do I prefer, this is actually not enough. I also have to configure each TUI application separately to have the color scheme that I like.

And I do not understand why people do it. Like, why would you deliberately break the universal customization system and force users to use your own, specific to your app?

Honesty, each time I encounter an app that uses 16-255 colors, I feel like someone just violated my personal space and intruded into my chosen color pallette with their own colors that don't fit.

Re: Terminals should generate the 256-color palette

#46

Post by robinsonb5 »

iberator wrote: post #43
robinsonb5 wrote: post #25

Earlier quoted context omitted.

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.

there is TCL-TK. :) Super easy to use, fast, almost zero ram usage and battle tested for 2 decades.

"Equally jarring and out-of-place on all platforms" isn't quite what I asked for, but I guess it's the next best thing! ;)

Re: Terminals should generate the 256-color palette

#47

Post by AshamedCaptain »

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…

Sadly, if users start customizing the 256 color palette, developers will simply switch to true color to continue this mess further...

Re: Terminals should generate the 256-color palette

#48

Post by donatj »

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…

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

Re: Terminals should generate the 256-color palette

#49

Post by ale42 »

mr_toad wrote: post #40
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…

> it's not clear to me what type of work those people are doing. 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.

> Anything that can be done in a terminal can be scripted and automated

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.

Re: Terminals should generate the 256-color palette

#50

Post by johncoltrane »

vova_hn2 wrote: post #45
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'm sorry, but I find this mentality from app developers extremely annoying. I personally prefer light themes everywhere, both in IDEs and in the terminal. I thought that just choosing my own color scheme for 0-15 would give me the color pallette that I prefer, but because app developers like you for some reason decided that you know better what colors do I prefer, this is actually not enough. I also have to configur…

I'm not an app developper. I make third-party colorschemes for Vim, which I assume are downloaded, installed, and used by people on their own volition, after they have looked at, and liked, the screenshots. Moreover, I take great care to make sure they are still usable in 16c, within reason.

Because all my work is based on 16-255, I can actually guarantee to my users that, given a properly configured terminal emulator, they will get the colors on the screenshots.

If I can't rely on 16-255 to be fixed anymore, then I won't be able to make any promise anymore. In practice, it just means adding a caveat in the README.md, but I'd prefer not to. Here's hoping this breaking change gets hidden behind a checkbox/flag.

Post reply on HN