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

191–200 of 212 posts

Re: Terminals should generate the 256-color palette

#191

Post by flomo »

gjvc wrote: post #30
flomo wrote: post #18

If any end users actually cared about terminal/TUI apps, there would be modern APIs for whatever they want. Since this is really just a legacy system operator monk / retrocool interface, they spend years debating ancient DEC theology.

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.

Re: Terminals should generate the 256-color palette

#192

Post by duskdozer »

ryandrake wrote: post #79
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.

Yes, and giving developers control over colors, text size, typeface and so on has also been a usability and accessibility disaster on the web, too! The user should have this control.

and animations... my bane...

Re: Terminals should generate the 256-color palette

#193

Post by duskdozer »

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

This will be fascinating to see in practice, with ghostty for example shipping these changes! I expect that the concern you have here will largely be for naught, with some exception. What are some terminal apps you think might be affected, what are test cases? I didn't read in fully, but what I was thinking in my head is not that we would just totally replace the rest of the colors with arbitrary palette. But that we…

>Apps & designers want their own brand identity

This is the main issue as I see it. Obviously I'd prefer to need to customize less, but as long as I have the option to override the defaults, I don't care much about what those defaults are. But the concept of "branding" flies right in the face of this.

Re: Terminals should generate the 256-color palette

#194

Post by anthk »

wredcoll wrote: post #167
anthk wrote: post #164

Earlier quoted context omitted.

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?

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 =)

Re: Terminals should generate the 256-color palette

#195

Post by anthk »

wang_li wrote: post #185
anthk wrote: post #154

Earlier quoted context omitted.

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.

9front went further; you don't need to care about TTY's and PTY's any more except for the 'vt' tool which was made OFC to connect to Unix terminals and to run some legacy software thru APE/NPE (minimal POSIX compat modules).

The core concept of Unix weren't the terminals, but text, pipes and the orthogonal composability. rc under 9front doesn't need a terminal emulating some DEC hardware crudely. You get a shell not bound to sizes. Scripts run in the same way, but with superior editing capabilities.

Re: Terminals should generate the 256-color palette

#196

Post by anthk »

networked wrote: post #183
pjmlp wrote: post #172

Earlier quoted context omitted.

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

The concept of an XTerm it's far inferior to Emacs either as a REPL with a shell (eshell), the scratch buffer of the whole Elisp environment. Ditto with 9front with remote mounts and device binding. When you can use a remote component you can do NAT by importing /net in the spot from a remote machine. When you import /proc from another one you can suddenly debug processes of another machine.

Acme with shells are still far superior too. I can edit and script the editor's content and panes and run scripts on them. I can reuse Acme as a Mail, Usenet and maybe Irc client on the spot. I can cut, copy and paste with a mouse faster than a keyboard and yet maintain the Sam commands which are like the ex/ed ones but easier for some tasks (recursive searchs) without getting yourself mad with classic regexps. Heck, I can run filters a la vi under Acme but without being bound to a terminal and thus worried about the input/output on pipes.

Re: Terminals should generate the 256-color palette

#197

Post by anthk »

networked wrote: post #171
anthk wrote: post #159

Earlier quoted context omitted.

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

>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 and choose your own font for that window/tool. For instance, you can run sam with a totally different font than rio windows.

Re: Terminals should generate the 256-color palette

#198

Post by pjmlp »

networked wrote: post #183
pjmlp wrote: post #172

Earlier quoted context omitted.

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

Re: Terminals should generate the 256-color palette

#199

Post by worthless-trash »

gzread wrote: post #35
OJFord wrote: post #22

Earlier quoted context omitted.

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

You need support from third party software such as Xorg or Weston. On Windows, it just works.

I believe these are 'first party' software when it comes to linux.

Re: Terminals should generate the 256-color palette

#200

Post by networked »

anthk wrote: post #197
networked wrote: post #171

Earlier quoted context omitted.

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

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

Post reply on HN