3 ms·

Like you, I am not a huge fan of JS, but I'd like to say that the ideas behind TermKit — namely having a shell with richer graphical interaction (e.g. cat works

Like you, I am not a huge fan of JS, but I'd like to say that the ideas behind TermKit — namely having a shell with richer graphical interaction (e.g. cat works for images too), semantic awareness and tokenization of commands, rich autocomplete, etc. — were ahead of their time. 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.

naikrovek 5y ago
I am all about the larger intent behind TermKit, but intent alone cannot carry a project to success. 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.
- kergonath 5y ago
  > 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. 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.
  - naikrovek 5y ago
    I don't know; instead of seeing those failures as a shame, I see them as a learning opportunity. Those failures have taught us that graphics alone aren't compelling enough to drive adoption of those graphical features. 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.
    - georgia_peach 5y ago
      > PowerShell got this right 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.

naikrovek 5y ago

I am all about the larger intent behind TermKit, but intent alone cannot carry a project to success. 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.

kergonath 5y ago
> 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. 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.
- naikrovek 5y ago
  I don't know; instead of seeing those failures as a shame, I see them as a learning opportunity. Those failures have taught us that graphics alone aren't compelling enough to drive adoption of those graphical features. 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.
  - georgia_peach 5y ago
    > PowerShell got this right 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.