TermKit: A Rich Graphical Terminal (2011)
acko.net
acko.net
Is TermKit dead? Why? - https://news.ycombinator.com/item?id=4787211 - Nov 2012 (1 comment)
Why did TermKit die? - https://news.ycombinator.com/item?id=3154553 - Oct 2011 (1 comment)
TermKit - a graphical terminal replacement - https://news.ycombinator.com/item?id=2559734 - May 2011 (200 comments)
TermKit - Next Generation Terminal/Command Application - https://news.ycombinator.com/item?id=2542068 - May 2011 (2 comments)
The greatest failure of Linux is that it's not an operating system, but a kernel upon which dozens of operating systems are built. It seems to me like the number one reason why people don't use Linux is that there is no central authority over user experience, and thus no way to get everyone to standardize to something. This is not even remotely a problem with Windows and Mac OS! And you can see the problems with this architecture when you realize how ancient and arcane the terminal UX is. But until we ditch it, we'll be stuck in the land of POSIX forever.
when you realize how ancient and arcane the terminal UX is. But until we ditch it, we'll be stuck in the land of POSIX forever (which isn't necessarily a bad thing).
https://sw.kovidgoyal.net/kitty/protocol-extensions/
It seems the way it will work these days is that the maintainer/s of a popular terminal emulator put some careful thought and effort into an extension; maintainers of others then recognize the benefit and follow-up with feedback and complementary implementations that over time might drive toward a de facto standard.
I'm also not fond of the hyperlink extension that some terminals are adopting. We already know of the risk with emails and hyperlink URLs pointing to different locations (eg <a href="not.google.com">google.com</a>) the last thing we need is the terminal to also be exploitable.
I think some CLI users are looking at websites lustfully and wanting to emulate some of those features and while I'm all for improvements (better image support is always the obvious example but I'm all for inlining other forms of documents too) we definitely shouldn't be taking all the webs features wholesale without having a serious pause for consideration about the risks they might introduce. Particularly when a lot of organizations are still reliant on SSHing into remote servers.
the fewer places that JavaScript can escape to, the better, and terminals adopting anything that looks like web tech is such an alarmingly bad idea that I don't even know where to begin to address any arguments for that approach.
TermKit deserved to die because of its JavaScript nature alone.
Maybe it's expected that TermKit-the-project died, but I don't think that TermKit-the-idea should: whether it be bringing features from the project as extensions to existing terminals (cat for images would be nice), or building a new TermKit built on modern graphics libraries powered by WASM/Lua/bring-your-own scripting language.
A successful replacement for current textual shells will not look anything like the textual shells we have today; everything will be reimagined and will make sense, and will be very foreign to you and I.
A shell with graphics tacked on is not the revolution needed in this space. Waveform Graphics, Sixel and ReGIS (please look those up if you are not familiar) came to DEC terminals in the 1970s and 1980s, and still do not have widespread adoption. The addition of graphics isn't enough on its own, with or without new programs to blend the border between text and imagery.
A true leap is required to gain market share in this space. Simple evolution of the existing shell experience is just simply not enough. TermKit, Waveform Graphics, Sixel, and ReGIS effectively prove this.
I can not say that I know what whatever replaces our current terminals will be, but it will not look like TermKit. Or ReGIS, or Sixel.
And that’s a damn shame. Sixel might not be perfect, but it is very useful to be able to see images over ssh without having to use an X tunnel. Gnuplot with its sixel terminal in a tmux session is a decent dashboard, lightweight and which pretty much requires no setup.
You must redesign the terminal experience from the ground up and include graphics from inception if this is ever going to take hold.
There's lots of things that are wrong with current-day terminal paradigms. For example, to turn on an option for a command, you start the command-line option with `-`. To subtract, or turn off, you use `+`. Things like this are just proof positive to me that things need to be rethought from the ground level - the very basic core principles of what a terminal is actually for need to be considered and modernized.
Lots of people don't understand that the purpose of a terminal is to have a back-and-forth conversation with the computer. You say something in the form of a command, and the computer says something back in the form of command output and/or errors. Find ways to augment that conversation meaningfully, and you'll be on the right track. Everyone knows it's a back and forth, but few realize that this is what makes a conversation.
Passing the output of one program to the input of another should not be done as text, either; it's too limiting; it's as far from strongly typed as you can get, and you require that every program include a text parsing library. Objects should be passed, ideally self-describing ones. PowerShell got this right, at least partially. When you run a command alone, without piping or writing to a file, text is shown (because without redirecting, output is inherently piped to the terminal itself, and the terminal knows how to serialize those as text) but if you pass to another program, objects are passed and used as-is. (This is more along the lines of what Alan Kay meant when he coined the term "object oriented", as I understand it.) Passing messages around.
I think it's more of a trade-off between portability & ergonomics. PowerShell wins on ergonomics, but that also commits the developer to a fairly large binary encoding interface when something smaller would do. Windows does more of the lifting for me, but it also locks me into their ghetto. And even if the whole object encoding format were already wrapped up into a nice MIT licensed library, I might not want to commit to another dependency just to output a little text.
The nice thing about text is that (with UTF-8 at least), I don't have to worry about endianness (like when ssh-ing something over the wire, to a machine with a different OS and/or architecture), and we know not to trust it. Serialization/deserialization has a cost, but not a terribly steep one.
I believe the bazaar has won for a reason here.
there are many ways to implement such an idea, and PowerShell is only one of those ways. I think PowerShell did it well, and I recognize that there could be better ways.
separate the idea from the implementation.
> ...I might not want to commit to another dependency just to output a little text.
how complex of a dependency do you think that would be? "number of dependencies" is not a valuable metric; "complexity added by dependencies" is definitely valuable, so consider that, instead. a dependency which allows textual output, if it somehow weren't already in the pipeline, would be very small indeed, and would add almost zero complexity to the project.
and I don't think individual applications are the right place to add this, anyway. the terminal/shell should know what to do if the object you pass to STDOUT is self-describing.
Outside of optimizing-away a pipe (built-ins vs processes), I'm not sure if the shell even needs to figure into this.
Several of the newer terminals already support base64 png/gif/jpeg escape codes (ex: https://iterm2.com/documentation-images.html). Get the different projects on-board for a new escape code to handle a full-blown MIME blob (make it work just like image, but w/ mandatory mime type prefix), then everything would be covered.
The boundaries of concern between process/shell/terminal were fairly well-drawn to begin with. Some form of mandatory interchange more structured than "get a byte, get a byte, get a byte, byte, byte" is just going to end up as another VM ghetto like emacs. I like emacs, but one is enough.
TermKit is an excellent set of ideas to try to push further, but there's so much friction to just getting started with it, just trying it out. where-as the rwgular terminal is just there, single process, on our systems.
as for growability, community adoption, there are more hurdles. js isnt one thing. it's a vast vast sea of libraries & tools. even if termkit does show promise, so many js developers wont quitw understand or enjoy the particular tool/library choices made. TermKit is just before React, node.js is still quite new; it's just as JS started really settling, but barely. it's hard to imagine it would have been an ideal, modernly hackable form of js.
i still think dis-unity is a strength, that it's good that we're exploring widely, that we havent fully settled & let ossification set in. but it does mean new radical ideas have much smaller communities to support them.
I suggest you learn more about JavaScript, including its origin, its growth, its limitations, and its strengths, then do the same for several other languages.
if you do this, you will either see JS as the cancer it is, or you will lie to yourself and say you have "won" this discussion.
JavaScript has succeeded only because web browsers have carried it. it doesn't have enough merit to exist on its own, especially if you measure that by the JavaScript that existed early on. that was rubbish (though much simpler rubbish than today's variants) and if it weren't for the parasitic nature of JavaScript it would have died when it should have died. now, because it has been around so long and sees so much use, people believe it is a valid choice for other things. it really isn't.
I'm not a JS fan, but it doesn't strike me as any worse than any other piece of the ocean of half baked crap I have to wade through to make a working non-suckless application.
Unfortunately, most of these features are not supported by our terminal applications (Apple's Terminal supports double width and height, at least, and xterm can do Tektronix graphics) and libraries such as ncurses allow us to write software using many of those features having to understand the control sequences (most terminals today look like xterm). If we could push for support to these features, we'd have an already proven, probably supported by ancient software that we run today but that we never saw as intended, set of standards and functionality we could rely on. If all terminals, for instance, supported sixel graphics (a horrible standard, BTW) or DRCS (a meh one), we wouldn't need font support for character graphics (Unicode v13 has new Teletext block graphics, and 4x2 mosaics will be added soon, and libraries such as VTE implement those without font support) or "powerline" symbols.
I am thinking of the BLIT terminal: https://en.wikipedia.org/wiki/Blit_(computer_terminal)
Arguably that extended to 8½: https://en.wikipedia.org/wiki/8%C2%BD_(Plan_9)
... and thence Rio: https://en.wikipedia.org/wiki/Rio_(windowing_system)
... and thence 9wm: https://en.wikipedia.org/wiki/9wm
... which leads to eight or more further references and starts to need a map. :-)
The other ancestor which seems relevant being the Oberon TUI, which informed and inspired Plan 9: http://ignorethecode.net/blog/2009/04/22/oberon/
ISTM that there is or are lots more relevant things to the general concept of "let's extend the shell to that it makes intelligent use of graphics, pointing-device input and so on" such as Symbolics OpenGenera, and come to that, Interlisp, but then you disappear down pathways (Wirthian languages, Lisps etc.) that tend to turn off xNix folks.
Last year I also started playing around with WASM and building a terminal emulator in it. The idea being if I can manage the terminal emulator then I can add more features / friendlier UI/UX that might compliment non-CLI users who have been tasked with using the terminal; while power users still have access to the features of the $SHELL in their preferred terminal emulator. There is definitely overlap between what I'm doing and TermKit.
The idea of doing it this way means I'm still leveraging the foundations already in common use. Opinions about whether they're ready to be deprecated aside, it's the standard everyone already uses so trying to displace that would be an even big hurdle than even just trying to displace Bash. But at least if the standards are reused and extended it does mean people can pick and chose the items that work for them rather than forcing them into an "all or nothing" type scenario.
I'm not far down the terminal emulator route yet and it's definitely a task that is bigger than the time I personally have to commit to it. So I welcome any time and/or support anyone is willing to donate.
I should write a blog post about this at some point too....
The shell (in it's current form): https://github.com/lmorg/murex (docs on Github too but also accessible via https://murex.rocks )
If we had an "ASCII QOIF", you could dramatically beat BMP, most of the time, and be within 33% of a PNG, in many cases.
People just did not adopt them for other projects.
The thing that most people will possibly never understand is that the reason people do things is generally not rational. And often the better an idea is, the less likely it is to be adopted soon. So the fact that something doesn't become popular does NOT mean it doesn't have technical merit or legs. Actually it often means the opposite.
Humans, including programmers, are very similar to sheep. And I don't mean that in a joking way. I mean literally their behavior, including what tools they use for programming, is largely decided subconsciously by the activity of the other humans around them.
This for macs and winodows with literally dumb UX for development