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

171–180 of 212 posts

Re: Terminals should generate the 256-color palette

#171

Post by networked »

anthk wrote: post #159
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…

No, it's the opposite. in order to send commands to a hosts you shouldn't need a terminal emulator (twice or thrice, depending on the SSH, tmux and the VTY subsystem under Unix) and even sending baud information. 9front just gives you the graphical window and the shell. Mosh? Ok, 9p and more can be almost stateless in order to not drop the connections. Still, you aren't bound to neither escape codes nor to crude hack…

I don't think there is a client that will let me connect to 9front from Android, is there?

I see what you mean in this and the other comment. With 9front, you rely less on issuing commands to remote machines because you can directly access their resources. It's worth keeping in mind when comparing Plan 9 and Unix from a Unix user's perspective.

Being able to pick large fonts on the server isn't the same as leaving the fonts up to the client. 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).

> I consider the Sam regular expresions far more powerful than the vi keys themselves.

I agree, structural regular expressions seem like a better version of vi commands. It was reasonably easy to make some complex edits in https://github.com/martanne/vis when I tried it, and it felt like I'd only scratched the surface. I could see myself still using vis if it had tabs like Vim. (Tabs are a stated non-goal for vis.)

Re: Terminals should generate the 256-color palette

#172

Post by pjmlp »

networked wrote: post #161
pjmlp wrote: post #145

Earlier quoted context omitted.

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

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 Core/Nano, it can be done via Web GUI administration, or PowerShell remoting.

Re: Terminals should generate the 256-color palette

#173

Post by rbanffy »

I’m concerned not everyone have their base colors set sensibly - as in “there’s no guarantee the base garish RGB green is green on this machine”. Maybe the right thing would be to put the color closest to a base color on the corresponding corner of the RGB cube, but that’s also not ideal - I have had terminal palettes that were all green or all orange/red, or the green/yellow of EL displays.

Maybe applying the saturation of the base set across all the generated palette would also work.

Re: Terminals should generate the 256-color palette

#174

Post by tasuki »

Ferret7446 wrote: post #69
tasuki wrote: post #57

I had exactly this thought! Though, I have a problem with even just the basic 16 colours: black red green yellow blue magenta cyan white bright black bright red bright green bright yellow bright blue bright magenta bright cyan bright white ~~~ Many themes take `black` to mean `black` and `white` to mean `white`. How is it supposed to work when one switches the theme between the dark and the light version? What are `b…

The way it's supposed to work is you don't touch the terminal colors but instead configure the program to use different colors. So you don't invert black for a dark theme, instead the program uses white instead of black. By the way, the terminal foreground and background colors are independent of the standard 16 colors, which complicates things.

> The way it's supposed to work is you don't touch the terminal colors but instead configure the program to use different colors.

That makes sense, but... seems infeasible in practice? "The program"? I tell you what program I need to configure: all of them! Ideally even the programs I'm not even using yet.

I think I'll continue doing it my wrong way then: redefining the meanings to mean less/more contrasty. That allows me to effortlessly switch the terminal between light[0] and dark[1] backgrounds. I've done worse things: I also hijacked a part of the 256-colors-cube for my own purposes...

[0]: https://github.com/tasuki/dotrc/blob/master/.config/kitty/so...

[1]: https://github.com/tasuki/dotrc/blob/master/.config/kitty/so...

Re: Terminals should generate the 256-color palette

#175

Post by amelius »

ux266478 wrote: post #111
amelius wrote: post #37

Earlier quoted context omitted.

Ok, maybe I should have said "framebuffers" instead of images. Because that Kitty protocol seems limited in that interaction was not one of their goals.

What's the point? If you want a framebuffer, ask the windowing system for one. Why go through a terminal emulator?

Because this one works through screen/tmux, and works over ssh without messing with DISPLAY variables and such.

Re: Terminals should generate the 256-color palette

#176

Post by zzo38computer »

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…

If I make a terminal emulator, I would probably not support true colours in text but only in pictures (and it would be possible to disable pictures). I probably would not implement 256-colours either, because I agree with you; the user configures their own colours to use, and the terminal should use them. For text, only sixteen colours can be used.

Similarly, the user can also set their own fonts for the terminal, just as you can with colours and other functions. (However, some programs will have a reason to configure the fonts and palettes for the specific use, although most won't and even if they do the user might disable those features.)

A program can have an option (possibly by environment variable) to disable colours entirely; this might be necessary even if you can disable colours in the terminal emulator, because a program might want to use such things as reverse video, underlined text, etc to indicate some things when colours are disabled. (Disabled colours can also be useful if you do not have a colour display or if you want to print out a screenshot without a colour printer.)

Re: Terminals should generate the 256-color palette

#177

Post by zzo38computer »

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…

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.

Re: Terminals should generate the 256-color palette

#178

Post by shimman »

lloeki wrote: post #19
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…

Terminals like iTerm2 have had a Minimum Contrast for a while that messes with (foreground) colours, sometimes very badly.

For far too long I'm ashamed to admit, I would use vim with the adventure time theme on iterm2. Looking at it now I'm shocked my eyes didn't bleed more. I think the worst part was that visual mode was neon yellow bold text with neon pink bg. Relying on visual mode quite a bit while using vim I was self inoculating my subconscious with stills of a poor Jackson Pollock imitator while on multiple different amphetamines. Hopefully I find out my resistance soon.

Re: Terminals should generate the 256-color palette

#179

Post by [deleted] »

pjmlp wrote: post #172
networked wrote: post #161

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…

[deleted]

Re: Terminals should generate the 256-color palette

#180

Post by kps »

hnlmorg wrote: post #170
kps wrote: 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…

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

After thinking about it a bit more, I think the specific details of that (i.e. inventing an extended colour mode) are not ideal.

One alternative: Assign semantics to colour indexes above 256.

Both of those have the disadvantage that they separate foreground and background colour, but a user really wants a combined semantic presentation. For instance, a user might want a warning message to be black text on a yellow background, and not have to rely on the program remembering to set both foreground and background to ‘warning’ colour.

So another possibility is just to invent new SGR numbers, e.g.

    Control         Purpose
    ------------    -------
    CSI 2 0 0 m    normal (undoes any CSI 1 x x m)
    CSI 2 0 1 m    emphasise
    CSI 2 0 2 m    de-emphasise
    CSI 2 0 3 m    error
    CSI 2 0 4 m    warning
    CSI 2 0 5 m    caution
    CSI 2 0 6 m    notice
    ⋮
Then the user can configure those as they please with any combination of foreground, background, weight, slant, etc.

I'm now thinking about writing up pros and cons of alternatives.

Post reply on HN