Live data from Hacker News

Terminals should generate the 256-color palette

gist.github.com

181–190 of 212 posts

Re: Terminals should generate the 256-color palette

#181
post #108

Earlier quoted context omitted.

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…

I like this idea, although I think that they should be only one code, which might program both the foreground and background (and font styles if applicable), rather than separate codes for foreground and for background.

Yes, since this morning, I've thought a little more and agree. (I just finished replying to another reply.)

Anyone interested, ping me (address in profile) and encourage me to set up a repo to discuss and formulate a concrete proposal.

Re: Terminals should generate the 256-color palette

#182
The word “should” is way too strong. It’s ultimately just a personal preference. For me I would prefer a two-tier approach.

There are different programs inside the terminal that I would prefer to have different color treatment. A full-fledged editor like emacs should have full 24-bit color support because I have already configured it to have my preferred color schemes and I prefer to switch themes inside emacs. On the other hand, almost all other TUI programs should not be permitted to use more than the traditional 16 colors. I haven’t configured them myself so I don’t trust them to make good choices.

In other words different terminal capabilities for different programs.

Re: Terminals should generate the 256-color palette

#183
post #172

Earlier quoted context omitted.

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…

You are missing the part that PowerShell has exactly a Xerox PARC like experience, first with PowerShell Integrated Scripting Environment, nowadays the same experience is available in VSCode. Replicating the experience of using something like Smalltalk transcript window. Of course Windows has SSH support, it needs to interoperate with UNIX, given that UNIX won the server room. No need for SSH to talk with Windows Cor…

> 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 administration, or PowerShell remoting.

I was thinking of the administrator connecting to Windows from their Mac or Linux/BSD machine. I don't know if that's a good idea compared to them getting a Windows VM and using Windows-to-Windows PowerShell remoting as you suggest.

Re: Terminals should generate the 256-color palette

#184
post #158

> If you've spent much time in the terminal, you've probably set a custom base16 theme. Hmm, I suspect that almost everyone who works in the terminal has never done this. I don’t really care what the colors look like, beyond choosing between whatever built in themes my terminal has. Is this really the minority experience?

I'm pretty sure the word "custom" refers to the act of choosing among builtin themes in the terminal. Some terminals like ghostty have hundreds builtin.

Re: Terminals should generate the 256-color palette

#185
post #154

Earlier quoted context omitted.

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.

Again, don't confuse the shell (command line interpreter) with a terminal with escape codes and the like. Check how 9font does it, you get the rc shell and a few more languages with a REPL (lua ports and the like) inside a graphical window , not by emulating a VT220 terminal running the shell inside. You can freely resize the 9front's rio window manager's windows running rc (or anything else, even games, graphical br…

You are confusing the unix terminal model with specific terminals. The TTY concept doesn't mandate an 80x24 text only device. Outside of applications that specifically rely upon the existence of a directly addressable grid of characters, Unix TTYs and PTYs would work perfectly fine in a mathematica notebook style interface.

Re: Terminals should generate the 256-color palette

#187

> Complex and color-heavy programs struggle with such a small palette. Damn if only there was some other system that could be operating with that in mind

I feel like you're saying one operating system does it better, but I fail to think of one.

Eh, i was being facetious, but really the point being it's kind of beyond the scope of what a terminal is for if we start plugging in full colour rendering. It is still cool.

Re: Terminals should generate the 256-color palette

#188
post #181

Earlier quoted context omitted.

I like this idea, although I think that they should be only one code, which might program both the foreground and background (and font styles if applicable), rather than separate codes for foreground and for background.

Yes, since this morning, I've thought a little more and agree. (I just finished replying to another reply.) Anyone interested, ping me (address in profile) and encourage me to set up a repo to discuss and formulate a concrete proposal.

OK, I've started making notes on this at https://codeberg.org/datatravelandexperiments/semantic-termi... . Feel free to jump in, or volunteer to adopt the whole thing.

Re: Terminals should generate the 256-color palette

#189
post #22
post #15

Earlier quoted context omitted.

Windows allows you to set any pixel to any 24-bit colour.

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

Apples shipping terminal is drastically featureless in comparison to a lot of third party terminals.

Re: Terminals should generate the 256-color palette

#190
post #122

Earlier quoted context omitted.

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.

You know its funny...

I had the same point a few days ago:

https://news.ycombinator.com/item?id=47005509#47012203

I feel like i'm talking crazy pills, computer still, and always will use blocks of memory, which can be parsed how i see fit. I will die on this hill.

Post reply on HN