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

201–210 of 212 posts

Re: Terminals should generate the 256-color palette

#201

Post by Sharlin »

SAI_Peregrinus wrote: post #109
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.

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.

The sensitivity of S cones is also simply much lower than that of the M cones. It's clear that pure (0, 0, 1) blue is perceived as vastly darker than pure (0, 1, 0) green. Blue light must be about 10x brighter (in linear intensity) than green light to be perceived as equally bright; the brightest full-saturation blue in sRGB looks about as bright as the very dark green (0, 0.1, 0). The contrast on black background is incredibly poor.

Re: Terminals should generate the 256-color palette

#202

Post by networked »

pjmlp wrote: post #198
networked wrote: post #183

Earlier quoted context omitted.

> Replicating the experience of using something like Smalltalk transcript window. As far as I know from Pharo, the Smalltalk transcript logs plain text and is less capable than xterm. So what you care about is not the capabilities of the terminal but having a long-lived interactive session/REPL or a REPL integrated with an editor? > No need for SSH to talk with Windows Core/Nano, it can be done via Web GUI administra…

How come a graphics powered REPL is less capable than a window that pretends to be a tty from the 1970's? You can certainly use the same Web GUIs from macOS and GNU/Linux as well, as for Powershell remoting, no need for VM when Powershell nowadays is written in modern portable .NET.

> How come a graphics powered REPL is less capable than a window that pretends to be a tty from the 1970's?

I mean the Smalltalk transcript and its capabilities alone, not Smalltalk as a whole. The transcript apparently just logs plain text; xterm supports color and text formatting like bold and italic. I'm guessing that, per https://news.ycombinator.com/item?id=47058849, you'd want fancy text displayed separately in the GUI.

> as for Powershell remoting, no need for VM when Powershell nowadays is written in modern portable .NET.

It looks like multiplatform PowerShell remoting uses SSH: https://learn.microsoft.com/en-us/powershell/scripting/secur.... You'd get a VM to use WinRM.

Re: Terminals should generate the 256-color palette

#203

Post by naikrovek »

wang_li wrote: post #125
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.

> I'd love Mathematica style notebooks for my shell work.

Atuin Desktop might be something of interest for you.

Re: Terminals should generate the 256-color palette

#204

Post by duskdozer »

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…

I'm not sure I understand - if you could have your way everything would be a GUI and no CLI? Or just terminals in their current form are not good?

Re: Terminals should generate the 256-color palette

#205

Post by anthk »

pjmlp wrote: post #118
donatj wrote: post #48

Earlier quoted context omitted.

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

Good TUI's arent bad for POS terminals and the like, where speed it's king, kinda like airports where the latency it's a matter of life of death. For everything else, just look at IBM: you have the old TUI with 3270 terminals and web 'bindings' to these to accomplish the same exact task but with a GUI interface.

But OFC some airport assistant has an AS400 console on it and that's it sending commands at blitzing speeds. These interfaces have sense there; but not for a modern desktop OS shell as the main debugging environment.

Re: Terminals should generate the 256-color palette

#206

Post by anthk »

networked wrote: post #202
pjmlp wrote: post #198

Earlier quoted context omitted.

How come a graphics powered REPL is less capable than a window that pretends to be a tty from the 1970's? You can certainly use the same Web GUIs from macOS and GNU/Linux as well, as for Powershell remoting, no need for VM when Powershell nowadays is written in modern portable .NET.

> How come a graphics powered REPL is less capable than a window that pretends to be a tty from the 1970's? I mean the Smalltalk transcript and its capabilities alone, not Smalltalk as a whole. The transcript apparently just logs plain text; xterm supports color and text formatting like bold and italic. I'm guessing that, per https://news.ycombinator.com/item?id=47058849 , you'd want fancy text displayed separately i…

The transcript on Smalltalk is a bad point when the environment itself (the object browser) it what matters in the end. You already have a logical browser far superior to boldted pipes under XTerm. Even 9front has a ndb(1) tool (not just useful for network settings) which can be reused as a small text database a la GNU recutils.

With rio windows I get an actual text stream to copy and paste (and grep and wahtnot), not the text, terminal control codes for bold and colour and often DEC decorations such as the ones in Nethack for walls.

Re: Terminals should generate the 256-color palette

#207

Post by anthk »

flomo wrote: post #191
gjvc wrote: post #30

Earlier quoted context omitted.

It's a shame to see you get downvoted (presumably because you don't cite any evidence for your assertions). As a counter-point, I will give the oft-quoted-by-me 1990s promotional video of the use of IBM CallPath on an AS/400 which should get you all misty-eyed https://youtu.be/5pY6Xxptp9A?t=2058 Enjoy.

IBM = heathen technology. The entire point is fetishization of not that.

IBM it's a special case. You often have the exact tools under the terminal interface and the GUI 1:1. You can do the same task in the CLI, TUI or with a GUI, now it can perfectly be over a web. But for minimum latency the CLI and TUI are essential and even a 9front user as me I acknowedge that. But 9front it's a special case too; it was basically made to be modular from day one and you can just set a CPU server and connect anything into it over 9p, be physical or not. No SSH needed, everything works the same everywhere.

Re: Terminals should generate the 256-color palette

#208

Post by anthk »

networked wrote: post #200
anthk wrote: post #197

Earlier quoted context omitted.

>Android Drawterm, for sure. It should be under FDroid. On 9p itself, check termux. > When I use terminal emulators, SSH, and tmux, I can switch between different clients with different resolution, pixel density, and screen orientation and have the text display acceptably on each (minus text reflow for history, which is an issue) Oh, I understand. But you can set the font= environment variable before launching a tool…

> Drawterm Cool, thanks. Sadly, F-Droid tells me their build is too old for my version of Android.

FDroid (at least some clients) allows you to get older Drawterm versions as well.

Re: Terminals should generate the 256-color palette

#209

Post by wredcoll »

anthk wrote: post #194
wredcoll wrote: post #167

Earlier quoted context omitted.

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?

No Perl but there's rc, awk and aux/* helper tools which can do tons of stuff Perl does but without calling tons of CPAN modules. 9front ships an IRC client made with rc, awk and aux/trampoline to connect (and tlsclient for TLS connections). On horoscopes, there's 9ching and tarico at https://shithub.us =)

I mean, the point here is the standardized input/output system that leta everyone build programs without knowing each other that more or less interoperate.

Re: Terminals should generate the 256-color palette

#210

Post by jve »

mort96 wrote: post #115
SAI_Peregrinus wrote: post #109

Earlier quoted context omitted.

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

There is a phenomenon where I call things blue where my wife call things green.

Now reading your comment perhaps that's why? And some eyes would gladly distinguish green rather than blue?

Post reply on HN