Hacker News new | comments | show | ask | jobs | submit login

I love this!

It has fundamental conceptional flaws. But hell, finally someone is rethinking the terminal, please continue working on this!

Here's the direction I would propose:

It must be 100% backwards compatible. This is not optional, anything else is a non-starter. Likewise trying to re-invent the entire unix userspace toolchain is a terrible idea.

So why not do it the UNIX-way and how terminals have always done it:

Start by emulating a normal terminal (xterm/vt10x). Add support for a special ESC-sequence that switches the terminal into TermKit mode (and another one to switch back).

This way we have a normal terminal, with a bonus-mode.

A simple cli-wrapper could be provided to mix the "magic" in. E.g. to cat a PNG I would: 'cat foo.png | tk_wrap'.

And on the screen that image would magically be embedded below my command line, just like any text output would.

tk_wrap would be small wrapper that first emits the termkit-esc, then the stdin-data (converted to the json meta-format), and finally the termkit-end-esc.

That's the basic architecture that I'd like to see. And from there, sky's the limit.

I hear what you're saying, but respectfully I disagree.

To me, it's like suggesting that the iPhone would be better if you added a physical slide out keyboard to make it more old-school; sure, you could do that, and would probably score popularity points with unconvinced customers.

But you would compromise tons of secondary aspects of the device to do so.

If TermKit would have a "traditional" mode of operation, and let you switch back to it, it would mean that TermKit has failed in being a comprehensive tool. I hope I can get around that.

You could put the "new" mode of operation directly against the "traditional" one only if you were proposing an actually new paradigm (like the point-and-click interface). And even then you would still want to allow a way to fall back to what's tried and true.

As TK is essentially an _improved terminal_, I don't see a reason to totally break off from the current power of the traditional CLI, especially if alienating current power users in the process.

The biggest limitation are the existing applications. Initially the new features could be opt-in, and as the new idea picks up, you would then have more and more console applications support the new type of terminal.

Thanks for replying, and I am the one to be respectful, as you are the one who is doing all the work. So please take all my comments as an attempt at constructive criticism. :-)

While I can understand your viewpoint I'm worried that it will prove difficult to gain mindshare by attempting to replace existing terminals instead of augmenting them. As long as I can't use TermKit as my only terminal my motivation to even try it is non-existant. And I'm sure most people are like me in that regard.

Either way, I hope you will keep on working on it, as I'd love to see terminals become smarter. Once it's fit to fully replace my iTerm I will give it a shot.

> TermKit has failed in being a comprehensive tool.

As it should. Unix disdains comprehensive tools in favor of the pipeline and, generally, picking the right tool for the job.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact