5 ms·

One of these seems to pop up every few months, which is great, terminals are old crusty awful things, but it seems like they always die out in development befor

One of these seems to pop up every few months, which is great, terminals are old crusty awful things, but it seems like they always die out in development before they can run existing things like Vim which makes them fun POC's and not much else :/

scotchio 11y ago
> One of these seems to pop up every few months Do you --or anyone reading this-- have a list of these? I would love to check them all out actually (not that I don't get your point).
- xnzakg 11y ago
  Well, there's Finalterm that doesn't exactly seem to like vim.
- ivank 11y ago
  https://github.com/unconed/TermKit https://github.com/unconed/TermKit https://github.com/breuleux/terminus https://github.com/breuleux/terminus https://github.com/substack/exterminate https://github.com/substack/exterminate
  - deleted 11y ago
    [deleted]
ibrahima 11y ago
I would really love it if one of these web-based terminals managed to stick around. Just being able to view images in a terminal would be amazing. The trouble with building on web technologies seems to be that the overhead is just too high (eg. Atom) considering how many terminals the average developer has open at a time. I guess at least since it's based on Electron, it might have more longevity than something built from a cobbled together base. Here's hoping!
- andrewstuart2 11y ago
  Feh is usually good enough for me. There's always catimg too if you really really want it in the terminal and don't care that it'll look terrible.
  - noobermin 11y ago
    +1 on feh, although it doesn't work with gifs, and the author isn't planning to implement that support.
    - whyever 11y ago
      SVG is also not supported.
- kuschku 11y ago
  But still, even with electron, it’s performance will be horrible. Several hundred MB RAM usage for a single Terminal window are just not acceptable. Somehow many devs today write their software under the assumption that a user with 2GB RAM or 4GB RAM will at all times only run one single piece of software.
  - steckerbrett 11y ago
    I liked the JavaScript IRC client which uses like 400MB of memory.
    - kuschku 11y ago
      Exactly. And this is somehow acceptable, or even "industry standard" today.
- userbinator 11y ago
  Just being able to view images in a terminal would be amazing What are the advantages of that over using a dedicated image viewer program?
tatterdemalion 11y ago
The problem seems to be that they come at things from the wrong direction - you can't run vim without being backwards compatible with at minimum terminfo pages, very likely vim also makes an assumption also that the terminal communicates over a tty, and possibly you may just need to support actual ANSI Escape Codes. You can't run anything else without that either. Running vim should be the first thing this terminal can do. Just like the web itself, any new teminal client needs to be backwards compatible with the capabilities of prior terminal clients, because programs that run in the terminal expect it. And if your terminal can't run the programs everyone runs in their terminals, no one will adopt your terminal. But many of these projects seem to have no intention of maintaining that backward compatibility. Some, like TermKit, fully conflate the terminal and the shell and even many UNIX utilities. You can't hope to supplant ANSI compatible terminals when you let them have the enormous advantage of running all the software anyone wants to run in a terminal that already exists. It would be like saying you have a new, better web browser that can't open any existing web pages. No idea if this particular project has learned from past examples and is backwards compatible or not. (EDIT: It doesn't have a terminfo page, so probably not.)
- shockone 11y ago
  It does indeed support ANSI codes. Not fully compatible with VT100 yet, but that's where I'm moving. Vim is functioning, but there are a lot of bugs. https://dl.dropboxusercontent.com/spa/dlqheu39w0arg9q/xxy316am.png https://dl.dropboxusercontent.com/spa/dlqheu39w0arg9q/xxy316... The problem with terminfo is that not every tool relies on it. I've seen many examples (hello, exa), when the codes are hard-coded to operate with xterm-256. So, I decided to pretend to be an xterm.
  - tatterdemalion 11y ago
    Hey thanks for replying & I hope my comments didn't seem snooty. I've thought a lot about how to solve this problem and was disappointed by the way some past attempts have just ignored the infrastructure that ensconses current terminals. And its a real shame that so many tools just hard-emit ANSI escape codes - there are even some TUI frameworks that do it. The problem I see is that you seem to have the terminal doing things like fuzzy matching input against PATH executables. But that's the shell's domain. The terminal should just expose commands for adding text items to a drop down under the cursor, and the shell should send the matches to the terminal. And capabilities like this should be clearly defined in a terminfo page (which you should definitely have, even if for non-custom capabilities it uses the same definitions as xterm), so that well-written apps can send this information if and only if those capabilities are defined. Of course this is a huge challenge, because if you do it this way your terminal doesn't do anything new until someone writes a program to run in it using its extended capabilities. So this creates a chicken and egg problem. But you can't come up with nearly as many interesting things for your terminal to do with cursor dropdowns as everyone in the world can if you're just exposing that in the same way the character grid is exposed.
coldtea 11y ago
The thing is, the web stack is not how to do it (for a prototype, maybe). As they say above, this thing would halt when you cat a 50MB file. It takes someone who's familiar with terminals, and can use a language fit for the task (and without too many depenedencies -- so if you built it in Haskell and I need the Platform and half of Cabal to build it, it will never fly -- and it being in Haskell it will not attrack many UNIX hands, who are the people familiar with Terminals most). So something like C, C++, Rust or Go.
- timmy-turner 11y ago
  No, I think integrating the web stack in a terminal is one of the better options. You'll get a lot of nice things that already work, e.g. serialization (HTML/CSS/JS/JSON), debugging (webkit dev tools, if you use webkit to render you terminal), libraries that are useful for terminal based apps (d3.js) and nice font rendering to only name a few. `cat 50mbfile` will not halt a web based terminal if you don't keep it all in the scrollback buffer.
otabdeveloper 11y ago
> terminals are old crusty awful things Not really, they're just poorly documented. They're based on ad-hoc standards that are scattered across many outdated documents. It'd be nice if somebody could actually pull all that together and publish one comprehensible document that is readable and up-to-date.

scotchio 11y ago

> One of these seems to pop up every few months Do you --or anyone reading this-- have a list of these? I would love to check them all out actually (not that I don't get your point).

xnzakg 11y ago
Well, there's Finalterm that doesn't exactly seem to like vim.
ivank 11y ago
https://github.com/unconed/TermKit https://github.com/unconed/TermKit https://github.com/breuleux/terminus https://github.com/breuleux/terminus https://github.com/substack/exterminate https://github.com/substack/exterminate
- deleted 11y ago
  [deleted]

ibrahima 11y ago

I would really love it if one of these web-based terminals managed to stick around. Just being able to view images in a terminal would be amazing. The trouble with building on web technologies seems to be that the overhead is just too high (eg. Atom) considering how many terminals the average developer has open at a time. I guess at least since it's based on Electron, it might have more longevity than something built from a cobbled together base. Here's hoping!

andrewstuart2 11y ago
Feh is usually good enough for me. There's always catimg too if you really really want it in the terminal and don't care that it'll look terrible.
- noobermin 11y ago
  +1 on feh, although it doesn't work with gifs, and the author isn't planning to implement that support.
  - whyever 11y ago
    SVG is also not supported.
kuschku 11y ago
But still, even with electron, it’s performance will be horrible. Several hundred MB RAM usage for a single Terminal window are just not acceptable. Somehow many devs today write their software under the assumption that a user with 2GB RAM or 4GB RAM will at all times only run one single piece of software.
- steckerbrett 11y ago
  I liked the JavaScript IRC client which uses like 400MB of memory.
  - kuschku 11y ago
    Exactly. And this is somehow acceptable, or even "industry standard" today.
userbinator 11y ago
Just being able to view images in a terminal would be amazing What are the advantages of that over using a dedicated image viewer program?

tatterdemalion 11y ago

The problem seems to be that they come at things from the wrong direction - you can't run vim without being backwards compatible with at minimum terminfo pages, very likely vim also makes an assumption also that the terminal communicates over a tty, and possibly you may just need to support actual ANSI Escape Codes. You can't run anything else without that either. Running vim should be the first thing this terminal can do. Just like the web itself, any new teminal client needs to be backwards compatible with the capabilities of prior terminal clients, because programs that run in the terminal expect it. And if your terminal can't run the programs everyone runs in their terminals, no one will adopt your terminal. But many of these projects seem to have no intention of maintaining that backward compatibility. Some, like TermKit, fully conflate the terminal and the shell and even many UNIX utilities. You can't hope to supplant ANSI compatible terminals when you let them have the enormous advantage of running all the software anyone wants to run in a terminal that already exists. It would be like saying you have a new, better web browser that can't open any existing web pages. No idea if this particular project has learned from past examples and is backwards compatible or not. (EDIT: It doesn't have a terminfo page, so probably not.)

shockone 11y ago
It does indeed support ANSI codes. Not fully compatible with VT100 yet, but that's where I'm moving. Vim is functioning, but there are a lot of bugs. https://dl.dropboxusercontent.com/spa/dlqheu39w0arg9q/xxy316am.png https://dl.dropboxusercontent.com/spa/dlqheu39w0arg9q/xxy316... The problem with terminfo is that not every tool relies on it. I've seen many examples (hello, exa), when the codes are hard-coded to operate with xterm-256. So, I decided to pretend to be an xterm.
- tatterdemalion 11y ago
  Hey thanks for replying & I hope my comments didn't seem snooty. I've thought a lot about how to solve this problem and was disappointed by the way some past attempts have just ignored the infrastructure that ensconses current terminals. And its a real shame that so many tools just hard-emit ANSI escape codes - there are even some TUI frameworks that do it. The problem I see is that you seem to have the terminal doing things like fuzzy matching input against PATH executables. But that's the shell's domain. The terminal should just expose commands for adding text items to a drop down under the cursor, and the shell should send the matches to the terminal. And capabilities like this should be clearly defined in a terminfo page (which you should definitely have, even if for non-custom capabilities it uses the same definitions as xterm), so that well-written apps can send this information if and only if those capabilities are defined. Of course this is a huge challenge, because if you do it this way your terminal doesn't do anything new until someone writes a program to run in it using its extended capabilities. So this creates a chicken and egg problem. But you can't come up with nearly as many interesting things for your terminal to do with cursor dropdowns as everyone in the world can if you're just exposing that in the same way the character grid is exposed.

coldtea 11y ago

The thing is, the web stack is not how to do it (for a prototype, maybe). As they say above, this thing would halt when you cat a 50MB file. It takes someone who's familiar with terminals, and can use a language fit for the task (and without too many depenedencies -- so if you built it in Haskell and I need the Platform and half of Cabal to build it, it will never fly -- and it being in Haskell it will not attrack many UNIX hands, who are the people familiar with Terminals most). So something like C, C++, Rust or Go.

timmy-turner 11y ago
No, I think integrating the web stack in a terminal is one of the better options. You'll get a lot of nice things that already work, e.g. serialization (HTML/CSS/JS/JSON), debugging (webkit dev tools, if you use webkit to render you terminal), libraries that are useful for terminal based apps (d3.js) and nice font rendering to only name a few. `cat 50mbfile` will not halt a web based terminal if you don't keep it all in the scrollback buffer.

otabdeveloper 11y ago

> terminals are old crusty awful things Not really, they're just poorly documented. They're based on ad-hoc standards that are scattered across many outdated documents. It'd be nice if somebody could actually pull all that together and publish one comprehensible document that is readable and up-to-date.