Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of the Terminal

gpanders.com

Post reply on HN
Print view View original

151–159 of 159 posts

Re: State of the Terminal

#151

Post by dartos »

Bjartr wrote: post #148
dartos wrote: post #31

Earlier quoted context omitted.

What assumptions specifically? Terminals, at the protocol level, assume nothing. It’s just streams of bytes which are processed then rendered. The protocol makes no technical assumptions, which is why it has both lived so long and is such a mess

One assumption is that it's one stream of bytes (Okay, two if you count stderr) and so control and metadata has to be interleaved with content to be displayed

I think that it’s a feature of the protocol that it’s stream based. It allows for a fairly responsive interface even in rough network conditions.

Re: State of the Terminal

#152

Post by Bjartr »

dartos wrote: post #151
Bjartr wrote: post #148

Earlier quoted context omitted.

One assumption is that it's one stream of bytes (Okay, two if you count stderr) and so control and metadata has to be interleaved with content to be displayed

I think that it’s a feature of the protocol that it’s stream based. It allows for a fairly responsive interface even in rough network conditions.

No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction. You could send the same data plus just enough bytes to know which data goes with which stream, then a terminal app could see a content stream and a control stream. I'm not spec-ing out a concrete protocol design here, just mentioning it is a fundamental assumption that leads to much of the (lack of) ergonomics in the current approach. Namely the interleaving of control characters and display characters. Any additional functionality we want needing to be squeezed down into that representation makes doing so cumbersome.

Re: State of the Terminal

#153

Post by 1vuio0pswjnm7 »

"This has a multitude of problems, however. The terminfo database is part of the ncurses library, and different operating systems and distributions package different versions of ncurses. This was a problem for tmux users on macOS for many years because the version of ncurses packaged with macOS was so old that it did not even include the tmux-256color terminfo entry at all!"

I build static Linux userlands from scratch using only busybox/toybox and a statically-linked GCC.

When compiling programs, e.g., tmux, I have been using netbsd-curses instead of ncurses.

After I compile tmux statically, the terminfo entries needed by tmux, i.e., needed by the curses libraries compiled into it, are contained by default in the directory $HOME/.terminfo. If nothing is found there, tmux then checks /usr/share/terminfo (or whatever path was use when compiling, e.g., /usr/local/share/terminfo).

This directory can of course exist apart from a curses library installed in a directory. In the userlands I make, there is no curses library installed in a directory after I have finished compiling all the programs.

For example, I can make a tarball of the terminfo directory from any suitable up-to-date distribution and untar it on the target computer.

Or I can make a hashed database of only the entries I need.

For me, the terminfo database is not "part of the curses library"; curses libraries provide an example terminfo database and a utility to compile terminfo entries. If the entries were truly part of the library, then one might argue they would be compiled into programs along with the library when compiling statically.

I keep a personalised copy of a terminfo database, i.e., a tarball of a terminfo directory, separate and apart from a curses library.

To be used with whatever curses library I choose. Not to suggest there is a great variety of curses libraries to choose from.

Re: State of the Terminal

#154

Post by dartos »

Bjartr wrote: post #152
dartos wrote: post #151

Earlier quoted context omitted.

I think that it’s a feature of the protocol that it’s stream based. It allows for a fairly responsive interface even in rough network conditions.

No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction. You could send the same data plus just enough bytes to know which data goes with which stream, then a terminal app could see a content stream and a control stream. I'm not spec-ing out a concrete protocol design here, just mentioning it is a fundamental assumption that leads to much of the (lack of) e…

> No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction

They aren’t as there isn’t any application protocol. Ncurses is the closest you’ll get. But several TUI frameworks exist (like ncurses and the charm.sh packages) which abstract the low level let’s call it a wire protocol

Re: State of the Terminal

#155

Post by camgunz »

9dev wrote: post #119
camgunz wrote: post #110

Earlier quoted context omitted.

There are libraries and frameworks that abstract this for you: ncurses, bubbletea, etc. At some point, every interface is low-level: GPU geometry is a stream of vertices, a program is a stream of bytes. This isn't some terminal-specific tech problem, it's just kind of how computers are.

Abstractions are layered a specific way, though. Layering upon something suboptimal will always be limited by the suboptimal layer. Ncurses or bubbletea et all may hide it from you, but they still only paint over the bumpy legacy wall below without being able to really improve on it.

"\033[31;1;4munderlines\033[0m" is (again) no worse than a stream of vertices or a stream of object code. Everything is a stream of bytes (well, a stream of bits anyway). Do you want CSS? Lipgloss is not too far off [0].

I read your objection basically as "escape sequences and control codes are noisy garbage"; are you saying something more like "the functionality you can achieve with escape sequences and control codes is fundamentally limited"? If that's the case, I don't see how, especially in the context of a character-based display.

[0]: https://github.com/charmbracelet/lipgloss?tab=readme-ov-file...

Re: State of the Terminal

#156

Post by Bjartr »

dartos wrote: post #154
Bjartr wrote: post #152

Earlier quoted context omitted.

No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction. You could send the same data plus just enough bytes to know which data goes with which stream, then a terminal app could see a content stream and a control stream. I'm not spec-ing out a concrete protocol design here, just mentioning it is a fundamental assumption that leads to much of the (lack of) e…

> No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction They aren’t as there isn’t any application protocol. Ncurses is the closest you’ll get. But several TUI frameworks exist (like ncurses and the charm.sh packages) which abstract the low level let’s call it a wire protocol

I know there isn't any. The topic is what innovations are possible. One possible innovation is to create such a protocol.

Re: State of the Terminal

#157

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #153

"This has a multitude of problems, however. The terminfo database is part of the ncurses library, and different operating systems and distributions package different versions of ncurses. This was a problem for tmux users on macOS for many years because the version of ncurses packaged with macOS was so old that it did not even include the tmux-256color terminfo entry at all!" I build static Linux userlands from scratc…

NetBSD curses actually does compile a few terminal descriptions into the library

https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/lib...

ansi

dumb

vt100

vt220

wsvt25

xterm

Unfortunately, netbsd-curses for Linux removed vt220 while almost tripling the size of the list

I prefer vt220 am not interested in 256 colors

https://raw.githubusercontent.com/sabotage-linux/netbsd-curs...

xterm

linux

xterm-256color

ansi

dumb

vt100

screen

screen-256color

tmux-256color

rxvt-unicode

rxvt-unicode-256color

st-256color

dvtm

dvtm-256color

fbpad-256

Re: State of the Terminal

#158

Post by dartos »

Bjartr wrote: post #156
dartos wrote: post #154

Earlier quoted context omitted.

> No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction They aren’t as there isn’t any application protocol. Ncurses is the closest you’ll get. But several TUI frameworks exist (like ncurses and the charm.sh packages) which abstract the low level let’s call it a wire protocol

I know there isn't any. The topic is what innovations are possible. One possible innovation is to create such a protocol.

Sure, but I’m arguing that replacing the very minimal protocol with a heavier one would not be an innovation nor would it be useful at all as you would always need some kind of low level streaming protocol, unless you’re looking to replace pretty much all of Unix land, but that’s a whole different discussion.

Re: State of the Terminal

#159

Post by Bjartr »

dartos wrote: post #158
Bjartr wrote: post #156

Earlier quoted context omitted.

I know there isn't any. The topic is what innovations are possible. One possible innovation is to create such a protocol.

Sure, but I’m arguing that replacing the very minimal protocol with a heavier one would not be an innovation nor would it be useful at all as you would always need some kind of low level streaming protocol, unless you’re looking to replace pretty much all of Unix land, but that’s a whole different discussion.

I don't see why the mere existence of lower level transport details must preclude discussion of higher level developer ergonomics.
Post reply on HN