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

151–160 of 212 posts

Re: Terminals should generate the 256-color palette

#151

Post by Aardwolf »

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…

gdb (the debugger) sometimes prints dark blue text on a black background, which is unreadable. I customize the dark blue color when possible in VTE's due to this, but it's not always possible everywhere

But I wonder what the developers of gdb were using that made them not notice this

Re: Terminals should generate the 256-color palette

#152

Post by Aardwolf »

tracker1 wrote: post #140
kevin_thibedeau wrote: post #72

Earlier quoted context omitted.

Most of them are emulating the EGA/VGA palette which was a regression from the CGA terminal colors. https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...

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?

Re: Terminals should generate the 256-color palette

#153

Post by makapuf »

johncoltrane wrote: post #52
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.

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…

My proposal would be to define a set of intents for 0-15 with sensible defaults and let terminal themes assign any color they would like to those. 0 would be background, 7 for foreground , 1 for highlight, 3 for titles, 4 for frames and from there work on backgrounds also..

Re: Terminals should generate the 256-color palette

#154

Post by anthk »

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.

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 browsers, images, video players...), copy, paste, cut the text, save the history, grep the contents of a window's text itself and tons more.

Re: Terminals should generate the 256-color palette

#155

Post by anthk »

wredcoll wrote: post #130
anthk wrote: post #62

Earlier quoted context omitted.

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?

In 9front, a decades old fork of Plan9. It's basically more Unix than Unix itself, by expanding the 'everything it's a file motto' and now for real and leaving out useless VT220 emulators (and any TTY/serial emulating connections) for legacy stuff such as the 'vt' emulator itself running under a graphical window and, for instance, when running SSH against Unix machines sending you a PTY plus a shell.

Re: Terminals should generate the 256-color palette

#156

Post by NoGravitas »

ux266478 wrote: post #110
robinsonb5 wrote: post #46

Earlier quoted context omitted.

"Equally jarring and out-of-place on all platforms" isn't quite what I asked for, but I guess it's the next best thing! ;)

That hasn't been true for a while, it's easily the best of the bunch at this point. It's also always been trivial to change, which can't be said of the others.

I'd say it's easily the least bad of the bunch, anyway, if you're really committed to cross-platform.

Re: Terminals should generate the 256-color palette

#157

Post by skydhash »

Andrex wrote: post #112

Wild, potentially stupid thought: why couldn't a terminal let users supply a user.css like browsers? They'd only have to support the small subset of text styles.

Color 0 to 15 are user-customizable by all terminals I know of. Color 16 to 255 are standardized, and the same across all terminals. Most (good?) cli and TUI use the first sets, while any that uses the second set usually are used through a theme engine (per app customization though).

Re: Terminals should generate the 256-color palette

#158

Post by foldr »

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

Re: Terminals should generate the 256-color palette

#159

Post by anthk »

networked wrote: post #134
anthk wrote: post #58

Earlier quoted context omitted.

Unix downvoters should have a look on 9front (the most featureful/supported plan9 fork out there) in order to realize that you can follow the Unix philosophy (even more than OpenBSD itself) tossing the VT100 emulators to the legacy 'vt' emulator if you want somehow use ancient software (or SSH) while setting actual graphical windows with the shell running inside with no terminals at all. No more damn control codes me…

(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 hacks as SINWINCH and horrors to copy and paste text under Tmux/Screen. Don't get me started on trying to do such tasks with URL's.

Text? I do that under 9front, too. Heck, rc it's simpler there than sh itself. I can bind remote machines and use their scripts as if they were my own. I can import remote devices. I can do stuff without resorting to crude hacks with openssl and nc. C itself it's far simpler. Text, you say? No locales, and UTF8 everywhere. I can freely resize the windows and still cut and paste stuff like nothing. It's 2025. The closest workflow under Unix would be Bitlbee + any client for it, msmtp and mbsync for Email and any graphical client against the SLRN cache in order to be as usable.

Rio can use different fonts just fine, you know. There are several users using 24 px fonts on HD screens without no issues. With riow you get 'virtual desktops' a la cwm/i3 and the like.

>Three button mouse. I don't do mouse chords, but I get more universal copy and paste as I stated that the old Unix itself, with shorter and easier scripts again... than Unix.

On snarf/paste instead of the menu, modyfing rio/sam and the like for a keybinding can be something done under an afternoon. Riow can already manage windows and close then with keybings among the mentioned virtual desktops.

Oh, and BTW... for vi users... I consider the Sam regular expresions far more powerful than the vi keys themselves. I can highlight the text with the mouse and write a sam command (on acme too) which affects the selection and in an easier way than the old syntax. The best of both worlds. RSI? Well, that's a point for Unix, but with the Windows key + 1-4 the mouse usage can be reduced a lot.

And, again, the 9front API it's dumb simple; I'm pretty sure doing stuff like mapping the Windows key +j-k-l to mouse button 1-2-3 would be something relatively easy, even setting sticky menus. With that small patch tons of usability issues would go away. Meanwhile, under X.org, Wayland, evdev and the $toolkit of the day... good luck.

Re: Terminals should generate the 256-color palette

#160

Post by anthk »

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…

With 9front you don't use SSH except against Unix. The motho there is too use 9p and import remote 'cpus', devices, auth against different servers... total orthogonality. You can spawn remote windows as if they were local. Heck, you can debug remote processes as if they were local too. By comparison SSH looks primitive...
Post reply on HN