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

121–130 of 212 posts

Re: Terminals should generate the 256-color palette

#121

Post by wredcoll »

tambourine_man wrote: post #82
johncoltrane wrote: post #52

Earlier quoted context omitted.

First, I make third-party Vim colorschemes, not app. People install my colorschemes because they like the colors, not because I'm a monster with a gun pointed at their face. No one is harmed. No one is forced to do anything they don't want. Outside of my text editor, where colors matter a lot to me for syntax highlighting, I'm definitely in the NO_COLORS camp (and in the NO_EMOJI camp, nowadays). > Color usage in the…

Can you link to your Vim colorschemes? I have a light and a dark one that I hacked over the years but I'm always looking for new ones.

Can you share your light one? I've never been able to find a white background scheme I actually love, rather than tolerate...

Re: Terminals should generate the 256-color palette

#122

Post by xvilka »

delaminator wrote: post #119
anthk wrote: post #56

Earlier quoted context omitted.

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.

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.

Re: Terminals should generate the 256-color palette

#123

Post by wredcoll »

johncoltrane wrote: post #12
jauntywundrkind wrote: post #7

Earlier quoted context omitted.

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…

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

I feel like any term that had this feature would also fully support truecolor, which suggests a way forward.

Re: Terminals should generate the 256-color palette

#125

Post by wang_li »

anthk wrote: post #102

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)

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.

Re: Terminals should generate the 256-color palette

#126

Post by thayne »

DiabloD3 wrote: post #124

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

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.

Re: Terminals should generate the 256-color palette

#127

Post by hnlmorg »

mort96 wrote: post #103
johncoltrane wrote: post #99

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.

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.

Quite a few terminal emulators do this already. Including the one I maintain.

Re: Terminals should generate the 256-color palette

#128

Post by wredcoll »

xvilka wrote: post #122
delaminator wrote: post #119

Earlier quoted context omitted.

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

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…

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.

Re: Terminals should generate the 256-color palette

#129

Post by hnlmorg »

johncoltrane wrote: post #106
mort96 wrote: 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…

> the current de-facto standard is set by xterm.

That’s true for 256 colour and various other escape codes too. But I wouldn’t say it’s true for 16 colour pallet.

Re: Terminals should generate the 256-color palette

#130

Post by wredcoll »

anthk wrote: post #62
tezza wrote: post #26

Earlier quoted context omitted.

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

Sure, I get the theory, so why doesn't exist? Where's my modern text/command based interface?
Post reply on HN