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

161–170 of 212 posts

Re: Terminals should generate the 256-color palette

#161

Post by networked »

pjmlp wrote: post #145
networked wrote: post #134

Earlier quoted context omitted.

(I didn't downvote you.) Plan 9 made some really cool design decisions, and I keep looking for places to use 9P. I also believe that Plan 9, as an artifact of its era, bet too heavily on the mouse and pixel-mapped graphics. Text, character-cell terminal emulation, and SSH won for good reasons. "GUI > terminal" is a separate matter from "Plan 9 > Unix". In some important ways, even text with hacky escape codes is more…

> I also believe that Plan 9, as an artifact of its era, bet too heavily on the mouse and pixel-mapped graphics. Text, character-cell terminal emulation, and SSH won for good reasons. "GUI > terminal" is a separate matter from "Plan 9 > Unix". What era? That is exactly the workflow of everyone using macOS and Windows around here. Connecting to cloud environemnts is also done via a mix of RDP, VNC, Web GUI based tooli…

Classic Xerox PARC-derived GUIs are very useful but not a replacement for the terminal. I also connect to my workstation over RDP, then use a terminal emulator.

Windows is a good example of what I mean. Windows system administration has become unmistakably more text- and console-centric over time with the rise of PowerShell. Windows has started shipping an SSH service and made its graphical interface optional on the server.

The web has avoided falling into the same trap. Web UIs are, for the most part, delivered to the user as hypertext rather than rio-style pixels. They rarely hard-require a mouse and have adapted well to touchscreens. Graphics in new web UIs is usually vector (SVG).

Re: Terminals should generate the 256-color palette

#162

Post by skydhash »

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…

Terminal emulators are user facing. Most programs don’t care about the terminal and have no awareness of it. They communicate through streams of texts and that’s it. I use Emacs and it’s another text interface different from the standard terminal. Think dired, proced, magit…

Re: Terminals should generate the 256-color palette

#163

Post by tracker1 »

Aardwolf wrote: post #152
tracker1 wrote: post #140

Earlier quoted context omitted.

Not really, because the dark yellow (not brown) is used... it's similar, but not the same in most terminals... brown as dark yellow for cga was a kind of short to a different color mix than the natural position which most terminals now use... actual screen effectiveness/brightness is different as well. Kind of anal about this since I started with a lot of CGA and EGA displays when I was in my late teens and early 20s…

I have no idea if this was the reason behind turning the dark yellow into brown, but the brown was a much better looking color for DOS games so it was a good call They could also have done something about the two magentas though... E.g. made one of them orange?

The light red usually appeared somewhat orangy/peachy, it's generally used as flesh for ansi artworks.

ex: https://16colo.rs/pack/ice-200207a/ti-war.ice

Re: Terminals should generate the 256-color palette

#164

Post by anthk »

wredcoll wrote: post #132
pjmlp wrote: post #63

Earlier quoted context omitted.

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.

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

9front does that without emulating a terminal. Grep, cc, awk, walk (no find and magical incantations with -print0 there), functions instead of aliases on rc, better lists () in rc, and so on. And you can launch these command inside your graphical editor such as sam or better, Acme. And even as a pipe to selections.

Re: Terminals should generate the 256-color palette

#165

Post by tracker1 »

Aardwolf wrote: post #152
tracker1 wrote: post #140

Earlier quoted context omitted.

Not really, because the dark yellow (not brown) is used... it's similar, but not the same in most terminals... brown as dark yellow for cga was a kind of short to a different color mix than the natural position which most terminals now use... actual screen effectiveness/brightness is different as well. Kind of anal about this since I started with a lot of CGA and EGA displays when I was in my late teens and early 20s…

I have no idea if this was the reason behind turning the dark yellow into brown, but the brown was a much better looking color for DOS games so it was a good call They could also have done something about the two magentas though... E.g. made one of them orange?

I think it was just determined that brown would be more useful than the darker yellow in practice. Other xterm colors are also a bit off from CGA/EGA/VGA DOS colors.

Re: Terminals should generate the 256-color palette

#167

Post by wredcoll »

anthk wrote: post #164
wredcoll wrote: post #132

Earlier quoted context omitted.

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

9front does that without emulating a terminal. Grep, cc, awk, walk (no find and magical incantations with -print0 there), functions instead of aliases on rc, better lists () in rc, and so on. And you can launch these command inside your graphical editor such as sam or better, Acme. And even as a pipe to selections.

Ok, I'll bite: how? What's the secret sauce? And can I use it with some random perl program I downloaded that prints horoscopes?

Re: Terminals should generate the 256-color palette

#168

Post by wredcoll »

johncoltrane wrote: post #137
wredcoll wrote: post #121

Earlier quoted context omitted.

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

I prefer my background dark so light colorschemes are not really an area I've explored seriously. Also, dark colorschemes are much easier to design than light ones due to the disproportionate amount of light a white, say, background emits compared to the amount emitted by text. It dramatically reduces the number of colors you can use. I have one here: https://github.com/romainl/vim-sweet16 but it is intentionally wei…

=[

We have many millenia of books using black text on a white background with various colors added, why are computer monitors all of a sudden so special and annoying

Re: Terminals should generate the 256-color palette

#169

Post by hnlmorg »

wredcoll wrote: post #168
johncoltrane wrote: post #137

Earlier quoted context omitted.

I prefer my background dark so light colorschemes are not really an area I've explored seriously. Also, dark colorschemes are much easier to design than light ones due to the disproportionate amount of light a white, say, background emits compared to the amount emitted by text. It dramatically reduces the number of colors you can use. I have one here: https://github.com/romainl/vim-sweet16 but it is intentionally wei…

=[ We have many millenia of books using black text on a white background with various colors added, why are computer monitors all of a sudden so special and annoying

Because paper is naturally pale. So it would have been silly for people to colour them black.

And because monitors are giant light bulbs. So a large white background is harder on the eyes than black.

Re: Terminals should generate the 256-color palette

#170

Post by hnlmorg »

kps wrote: post #108
ryandrake wrote: post #86

Earlier quoted context omitted.

It would be much better if application developers (and web developers, too) -only- had access to semantic color labels like TEXT, BACKGROUND, ERROR, WARNING, INFO, HIGHLIGHT, and so on, rather than red, yellow, blue, green, black. I don’t want my applications to decide “this element must be red text on green background.” I want my applications to annotate the UI with things like “warning message” and “title.”

That could be done with a few influential terminal emulators adopting a consensus extension to ISO8613-6, like this: ESC[38:99: ‹purpose› m for foreground, ESC[48:99: ‹purpose› m for background. e.g. Foreground Background Purpose ----------- ----------- ------- ESC[38:99:0m ESC[48:99:0m normal ( same as ESC[39m and ESC[49m ) ESC[38:99:1m ESC[48:99:1m emphasise ESC[38:99:2m ESC[48:99:2m de-emphasise ESC[38:99:3m ESC[4…

This is a fantastic idea!

I’m working on a terminal emulator. It’s not big like Ghostty but this is something I might adopt

Post reply on HN