
TermKit - a graphical terminal replacement - pimeys
http://acko.net/blog/on-termkit
======
barrkel
It's funny, his 'ls' by default prints out an information-sparse grid of icons
(only showing 10 items with a horizontal scrollbar?), whereas when I use the
command-line, I'm looking for exactly the opposite of a GUI - an information-
dense table of text. I agree with the commenter that -r-xr-xr-x - or even 0555
- is far better than "you can't touch this" (which doesn't describe who can't
touch it, and in what ways). His "rich display" is actually a display of
poverty - it conveys less information than text.

The typing of file / stream data is interesting, but I don't think it's
realistic - it requires all tools to change virtually overnight to preserve
the headers. And it's not enough just to preserve headers; what if you pump
stuff out to a temporary file and read it in a few milliseconds later? What
about compound files, with data chopped out of them? If you want pretty
pictures, syntax highlighting etc., ISTM better to have an enriched terminal
communication protocol along with a couple of viewer programs which can render
data formats to it, rather than change the whole world to type every data flow
everywhere.

~~~
mikemaccana
On the other hand, ls isn't showing you the file type, and will never show you
content. And you're mixing presentation with content, which is poor
engineering - see the guys coming up with regexs to handle time because the
only way time is presented to them is as text,

Good shells have prompted object pipeline based tools before - PoSH is only a
few years old. And it's still possible for older tools to run with no
degradation in quality from their previous environments.

This is really compelling.

~~~
barrkel
ls shows file type by coloring - check out ~/.dircolors/dircolors/LS_COLORS
and ls --color=auto - and kind by extension - ls -F. Showing things like
thumbnails seems to me to be of limited use. When I want to see the directory
in all its glory, I'll do the moral equivalent of "cygstart/open/whatever .".
That'll give me a proper shell window designed for viewing content with
thumbnails etc., rather than trying to stick it into the terminal. I've had
enough experience with things like dodgy video decoders crashing the shell's
thumbnail preview mechanism to know I don't want that stuff anywhere near my
terminal unless I specifically ask for it.

Powershell - I do indeed wish Unix shells worked a little more like it for
jobs like parsing ps output portably across platforms, but it has poor
performance for what I use the shell for, because it doesn't run each pipeline
process as a separate process or thread - everything is single-threaded. I
frequently run sed, awk, grep, sort over multi-GB files and rely on processes
and job control (fork-join through mktemp, & and wait, and xargs -P) to make
it work quickly.

But if, as I mentioned, the terminal supported a richer communication protocol
- one smart enough to show render full 32-bit images including alpha - then a
version of ls could be written that does what his ls command does, without
needing to go as far as he does.

~~~
unconed
Consider these bugs to be fixed, not irreparable complaints ;).

------
bernardwilson
I had a similar idea about 10 years ago, but never got around to implementing
it.

I'm amazed at the amount of hatred directed towards this - as if the terminal
could in NO WAY be improved?!. But clearly it can. For example - wouldn't it
be nice to have a terminal status bar with your CWD / git branch / etc in,
without cluttering up space before $? Yep, you can use screen, and that
destroys your ability to use the scrollbars.

Or, consider filename completion. Wouldn't it be nice to show the intended
completions in a popup as you're typing (like web browsers do) ?

Why, when I do 'ls', can I not drag & drop one of the files to another finder
window? Why is the terminal forever isolated?

Why when I run 'mvn install', which generates umpteen bazillion lines of
output, can the result not be folded into a single line showing the summary,
that I could expand if I wished?

There's lots of scope for this kind of thing. My main concern would be whether
a single WebKit control is the right way to go - it'd be nice to, for example,
embed custom controls within the shell (but this might also be possible).

So I think it's an awesome idea.

~~~
burgerbrain
_"I'm amazed at the amount of hatred directed towards this - as if the
terminal could in NO WAY be improved?!"_

Improve it all you want, I'm totally into that. The problem is that once your
"terminal" ceases to be a terminal emulator then you lose so much it's pretty
unrecoverable.

Most of the things that you suggest are very much technically possible for a
shell (perhaps zsh with some extensions) running in xterm. You'd be left with
some sort of unholy combination of a rather modernized `mc` and an otherwise
modern shell, but it'd be a very interesting product.

tl;dr: We're not opposed to improving the 'terminal'. I'm opposed to 1)
mistaking "improving the terminal" with "improving the shell" and 2) _losing_
the _terminal_.

~~~
Tangaroa
A terminal emulator running on an object-oriented system like Termkit could
run vt100-friendly filters to convert everything to text before it is sent
down the line to the user. Users who did not know they were connecting to such
a system might not notice the difference.

~~~
burgerbrain
Although I am not entirely sure what you are attempting to communicate, what I
will say is this:

If you do not provide direct user access to a pseudo terminal through a
terminal emulator, then you will undoubtedly lose functionality. You need both
the pseudo-terminal and the terminal emulator. If you _do_ provide direct user
access to the pty through a terminal emulator, then what the hell is the rest
of the crap there for?

------
moe
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.

~~~
unconed
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.

~~~
tga
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.

------
telemachos
After seeing something about this yesterday, I said on Rstat.us/Twitter that I
thought it was pretty but disagreed with the whole premise. I still do, I
think, but I'm very impressed with how reasonable Steven's response was. He
wrote me and asked pretty much "Why?" I said essentially "Unix philosophy" and
attached the link that ended up in his blog post.[1] He wrote back and at some
point he wrote this post, probably replying to _all_ the people who were
taking snipes at him. So this is a long way around to say, kudos for being
gracious and serious in the face of people glibly writing off your hard work.

Having said that, I'm still not sold on the concept - yet. I've played with it
a bit this morning. Obviously it's still pretty alpha (more than one seize up
or crash), but that's fine. My larger problem is in figuring out how it would
fit into my daily work flow. After trying it out now, here are some concrete
issues:

\+ No monospace fonts for code. The output of _cat_ looks like teeny-tiny
website font. Things are no longer "lined up". That's bad.

\+ I can't use any applications that take over the terminal ( _irssi_ , _mutt_
, _vim_ , _less_ ). Steven says as much - it's not part of his design - but
for me it's a big problem. It means that even if I embrace TermKit, I _still_
need those 1980s terminals.

\+ No scripting language built in. As bad as shell scripting might be, I get
an absolute ton done with it. I don't want to give that up unless something
will make up for all that "getting shit done".[2]

\+ TermKit (maybe?) forces me to change habits I can't afford to lose. One
small, but I think important, example: If you try to run this:

    
    
        awk '{print $1}' file.txt
    

TermKit doesn't echo the single quotes. That is, you can type them, but they
don't show up on the screen. I'm not really sure what to do with that. Does
that mean I should stop typing them? Does that mean that I still _must_ type
them, but TermKit strips them because they aren't pretty? Does TermKit allow
me to do it either way? I'm going to need to remember how to quote things when
I log into a remote machine over _ssh_ , so if TermKit will force me to change
habits, that's a big, big problem. (After a few experiments, it seems like the
single quotes are still required. Without them, TermKit tokenizes the stream
differently. If that's the case, why refuse to echo them to the screen?)

[1] <http://www.faqs.org/docs/artu/ch01s06.html>

[2] Cf. Ryan Tomayko's Shell Haters talk: <http://shellhaters.heroku.com/>

~~~
unconed
To address some of your concerns:

\- Monospace fonts for code is definitely in. Try catting a .js file, it will
get syntax highlighted. Most likely, it doesn't recognize the mime type of
your file. It's using the old mime.types DB + some custom additions... also,
the highlighter I'm using only has so many languages defined. I looked for the
most comprehensive / least fail one.

\- Regarding vim... I admit I just don't like those tools. I can operate vim
just fine, but I hate every second of it. I would much rather be able to type
"edit file", have it open up the file in my local editor, and sync back saved
changes.

\- No scripting language... except the whole thing is built on Node.js... :)
What's not discussed in the article is that the UI is not tied to the shell at
all. You can just as easily make a back-end worker for SQL, for SFTP, for a
scripting console, etc. I haven't worked out how this works in the UI, but the
protocol supports it. Session types can be multiplexed freely over one socket.
Basically, for scripting, I think the command line is a shitty place for it,
and we should just switch to using a real language in its own little console
when needed.

\- Regarding habits... it's not my goal to break any without reason, just to
reduce the number of keystrokes. Consider it a bug. Regarding quotes... the
idea is WYSIWYG. If there is a visual divider, it's a separate argument.
Otherwise, it gets passed as a single unit. This may sometimes be buggy, the
Unix command support is 1 week old, and I hack on this very late at night.

~~~
unconed
And on another note... it's been hilarious how people have been questioning my
professional credentials just because I want to make something more usable.

I've implemented over a dozen RFCs, can match regexps with the best of them
and do know which end of a pipe does what ;).

~~~
roqetman
It is amusing how we hackers, who are supposed to embrace change, become as
Luddite as anyone else when our sacred tools are questioned. Personally I see
room for this and a whole lot more. I'd like to see an amalgam of this and the
traditional terminal (easy way to pull up a traditional terminal if you need
it). There is no need to "replace"; I think this makes a fine addition to a
hackers workspace.

~~~
colomon
Thing is, it's not about the tools being sacred. My problem with this is that
he's not just solving problems I don't have -- he's solving them in a way that
would make my problems worse!

For instance, I very rarely want more informations about the files from an
"ls" command; and if I did, I'd probably use Finder instead. On the other
hand, not having enough terminal real estate to display the entire directory
at once is a very frequent problem. From that perspective, adding icons is a
step in the wrong direction.

Thinking about it, if I were playing with making a better terminal, one of my
first lines of thought would be things that made it quick and easy to break
information out into other windows, because scrolling back and forth in the
terminal's buffer is a PITA.

Of course, this new terminal might be exactly what the author needs, and more
power to him if it is. There's no need for us all to use the same tools.
(Thanks heavens -- I want nothing to do with Emacs or vi!)

~~~
9999
"if I did, I'd probably use Finder instead."

The thing that strikes me as very, very cool about this project is that you
might not need the Finder at all any more.

~~~
colomon
See, here's the thing: I like Finder. It's not perfect, but sometimes it is
very handy. Even if TermKit ends up implementing the complete functionality of
Finder, I'm not sure why I'd particularly like to have that functionality in
my terminal window. And if it's only implementing the one Finder view I
virtually never use? Forget about it.

You know what would rock my world? A "lsf" command that emulated "ls" as much
as possible, but launched a Finder window appropriately sized to display the
results.

~~~
9999
I've always thought Raskin's ZUI held some promise as an alternative UI
paradigm. I'm pretty much a quicksilver addict now and use that to kind of
combine the command line and GUI desktop worlds a little bit more at least.

------
ZoFreX
It's a pity that this is so difficult to try. The blog post has so much detail
and effort put into it, but all that shine and polish disappears when you try
to install it.

Specifically Step 1 of the instructions[1] has a link titled "install node and
npm" [2] which has the line 'git clone git://github.com/ry/node.git', which is
incorrect. The correct URL (as far as I can tell) would be
'git://github.com/joyent/node.git'.

In addition the linked instructions say nothing of npm, which can be installed
quite easily by running 'curl <http://npmjs.org/install.sh> | sh' as root.

Back to the TermKit instructions again, and step 5 says 'git clone
git@github.com:unconed/TermKit.git --recursive', which didn't work for me.
What worked was 'git clone git://github.com/unconed/TermKit.git --recursive'.

Finally after all that, I just see 'You cannot use this version of the
application TermKit.app with this version of Mac OS X.'. Would have been nice
to mention that at the start.

[1]: <https://github.com/unconed/TermKit> [2]: <http://howtonode.org/how-to-
install-nodejs>

~~~
unconed
I don't mind, the project is in too rough a shape to interest anyone but
hackers. Please come back in a month.

~~~
ZoFreX
I get that it's not meant to be release quality yet, it's just a shame that
your blog post was so comprehensive and detailed and fell down on that last
point. Certainly spending half an hour installing software only to find out I
need to upgrade my OS X wasn't fun :(

------
philjackson
I really think Steven went about marketing this in the wrong way. It really
should have been dubbed as a terminal _alternative_. By calling it a
replacement he's just inviting a mass of critique which focuses on what it
lacks rather than what it offers over an xterm.

~~~
unconed
I really doubt that would have changed people's reaction. Besides, to be taken
seriously, I have to believe that TermKit can eventually be a fully functional
replacement.

As for being hard to try and not at a useful stage yet... hey, that's not my
problem. I wasn't the one who upvoted it all over the internets :).

------
JunkDNA
I'd like to offer a slightly different perspective on this. As someone who is
a hybrid hacker/biologist, I welcome something like TermKit. I have invested a
good chunk of time learning unix commands and the shell because lots of
scientific applications require it. Furthermore, as a data wrangler, the unix
tools are a necessity for quickly processing and pumping files around. I
_require_ unix to efficiently do my job. I often think, "Gosh, what do all
these other people _do_ when they need to do X?" where "X" is some ugly task
that I can hack some grep and sed commands together to accomplish. I don't
think most programmers understand the sheer number of exceptionally well-
educated, genuinely smart people who spend huge chunks of their day doing
menial "copy/paste" in Excel (because it's the only real tool they can use)
when they should be designing bridges, curing diseases, analyzing data, etc...

If you're a unix sysadmin or a full-time hacker, you can justify the cost in
time and effort of learning and memorizing all this stuff. In fact, you'd be
foolish not to. But there are a lot of people who don't spend all day in a
terminal. Nevertheless, they frequently _need_ the unix terminal to get
something done. A tool like TermKit could be a huge boost for those people
allowing them to bootstrap their knowledge without having to dive into the
deep end all at once.

There are legions of people out there who are smart enough to learn some bits
of unix if only the learning curve wasn't a sheer brick wall. If you need
evidence that man pages and "-h" don't cut it, start typing common unix
commands into google (xargs, tar, grep, etc...) and you'll almost always find
one of the top suggestions is "command_name examples" or something like that.
Why is that? My grandma isn't trying to use "xargs" I assure you. Someone with
enough knowledge of the unix command prompt to know they need xargs reads a
man page and they _still_ don't know how the hell to use the command properly.
That's a usability problem and there are modern ways to help with it (as is
demonstrated by all the things IDE's do to help programmers all the time).

I'm really excited to see where this goes. There are all sorts of
possibilities it opens up.

------
ChuckMcM
Excellent exploration of alternatives to the old 'terminal' application. It
would probably help for context to explore the Bell Labs 'BLIT' terminal and
the Digital Equipment Corp VT340 (color graphic terminal) and the Tektronix
4010/4014/4064 terminals. These had capabilities that augumented the basic
terminal stuff and made it prettier at least to use them.

The humorous thing for me is seeing the discussion which essentially devolves
into creating a new windows type metaphor but with a lot of keyboard
shortcuts.

It may sound pedantic but consider that the terminal is the terminal because
terminals define a keyboard driven user interface. A user interface is a
'vocabulary' which describes actions. Its vocabulary scales from a
communication channel that is 300 baud to one which has multi-megabaud
connectivity. You can create a different vocabulary (which is what the other
terminals above did) and get additional features.

And you can create an entirely new vocabulary if you're willing to change the
minimum connectivity channel bandwidth as well (I doubt TermKit would work
well over 300 baud for example). There was some good work done on this in the
80's with 'visual shells' on the PC and of course there is a ton of work that
IBM did in creating optimized terminal environments (with visuals no less) on
3270 terminals which were in many ways a pre-cursor to todays IDE tools,
although perhaps more like Eclipse. Their environment which ran airline
reservations was a good example of optimizing the vocabulary (key strokes)
against the variety of tasks an agent might need to do.

So rather than calling this a graphical terminal replacement (which it isn't)
calling it a visual UI which can be driven entirely by the keyboard might be
better. I think that fundamentally the "thing" about terminals that everyone
sort of 'gets' is that you don't have to use a mouse, you always know where
your 'focus' is, and there are millions of key combinations which you can use
to express certain actions. For some, that is simply 'living in emacs' for
others it could be something like this.

~~~
ianb
I bet TermKit would actually work awesome over 300 baud. The two-tier approach
-- a backend that executes commands and a frontend that displays stuff -- is
going to be pretty efficient (if you are only running the backend remotely).
Well... perhaps the chattiness of something like filename completion will be a
bit of a problem, but it'll still probably work better that more directly
interactive systems because it's working with a more abstracted protocol than
a terminal does.

------
jimmyjazz14
_"At the end of the day, Unix just has bad usability"_

I have to say I highly disagree with this statement but, I also disagree that
there is anything wrong with the classic terminal. I find a full screen
terminal with nothing but text as a thing of beauty. They remove all but the
most essential details and work on a very simple common format (text).

In a way this kinda makes me think of Windows Power Shell, which is trying to
replace the classic shell with a more object oriented shell, it has a lot of
good ideas but in ways it brings more complexity to the issue than most Unix
users are looking for. Seems like this project could probably take some ideas
from Power Shell though.

I certainly have nothing against this guys work but it is not really a classic
unix shell replacement and should probably not strive to be such a thing.

~~~
DanI-S
Text is a simple format, but text with intrinsic formatting is most definitely
not a simple format.

~~~
jimmyjazz14
yeah thats true, thats why I get why Power Shell took an approach of passing
object around as apposed to just text. I think I was thinking more from a
visual standpoint when I said that text is simple.

------
MatthewPhillips
Maybe I'm an old fogey but I'll stick with xterm and iterm. Having a terminal
where I can have the same experience whether logged into a *nix box, on osx,
or sshed into a remote server is far more appealing than being able to cat
images or having a pretty progress bar. If I want to make json more readable I
can just pipe it through one of the many json formatting scripts.

It might just be me but I find cocoa to be a bit boring and dated looking.
Unix terminals are timeless. A nice tiling windows manager with 5 terminals is
still one of the most beautiful set ups.

~~~
unconed
Note: the goal is to be able to run TermKit transparently over SSH. Maybe even
do an "apt-get install termkit-backend" for you if you wish.

------
caf
The first thing to realise is that the existing UNIX data processing tools
deal fall into two categories - those that process (including generate or
consume) an ordered sequence of text records (eg. sort, comm, uniq, awk, sed,
grep, tr, cut, find, xargs, ls...) , and those that process arbitrary binary
data (cat, dd). Most fall into the first category.

Now, while it might make sense to use a better interchange format than
"newline-separated text" for those ordered text records, I don't think that
adding other arbitrary data types is particularly useful, unless a way can be
found to make these arbitrary data types self-describing. This is because
there's little to no commonality in the types of processing that you do on
different data types: the article shows the example of "cat termkit.png", but
what does it mean to concatenate two images ("cat foo.png bar.gif"), or
concatenate an image with a text file? Making some assumptions, we can
certainly define arguably useful semantics for those, but what does it mean to
"sort" an image?

And how do we write "cat" to deal sensibly with currently unknown data types,
that will be defined in the future?

~~~
maratd
_And how do we write "cat" to deal sensibly with currently unknown data types,
that will be defined in the future?_

Progressive enhancement. You get magic for the obvious things and standard
behavior for the non-obvious. I still want the power and flexibility of my
vanilla terminal, but I want it to do more when it can.

I want to open up a remote terminal to another server, on the other side of
the planet, and do a "cat foo.png" so that I can see it. Better yet, I want to
do an "ls -la" and have it show me the standard output, plus all the
thumbnails of the images in the folder. I want to do a ton of other stuff too.
At the same time, if load up some esoteric weird 30-year-old thing I found on
the internet that I just compiled ... well, I expect that to work too. That's
a must.

Of course, wanting and having are two different things.

------
wooster
This comment thread, both here and on the blog post, is the best example of
stop energy being directed at forward motion I've seen in a long, long time:

<http://www.userland.com/whatIsStopEnergy>

Kudos to unconed for doing something remarkable. I look forward to seeing
where it goes from here.

~~~
l3vitat3
that's just a marketing site talking about a marketing term probably invented
by a marketing guy, I'm okay if this gets as widespread as apple devices (and
btw I really love my macbook pro) but I find it totally useless for the people
working day by day with terminals, time will have the last word

~~~
Sudarshan
Think of this as empowering people who will not use vi or emacs, but prefer
Eclipse or Visual Studio, to have a visually appealing arsenal of tools which
can be chained in a pipelined fashion.

What is wrong with that? Yahoo pipes for example provided pointy clickety
interface to mashing up data. Lot of people used it to do useful work.

It really does not matter if a even single sysadmin who already uses the shell
does not start using this. It just needs to have its OWN users that is all. If
you just consider ALL Eclipse users + ALL Visual Studio users, that is a HUGE
user base... Now the vi/emacs user may _feel_ superior to the others...

but in reality anyone in this world can have their own reasons to create
products and use various tools. All the best to the author of this tool for
taking the pain to code this...

If it works out and gains users... awesome... else it shows we still find Old
tools useful. We have not stopped using Fire or Wheels today though they very
OLD technologies. Whether the shell is as important as fire or wheels OR
transitionary like Hydrogen blimps or something in between only time will
tell...

------
rrrazdan
Many times you need to look beneath the veneer of abstractions that is the
modern GUI, to work with speed and flexibility. However you don't want to
strip away all the abstractions. That would yield the system very unwieldy.
(example: Programming in C vs Programming in Assembly) The Unix command prompt
is just the right amount of abstraction for me, and for many other users. What
the project proposes is certainly novel, and this level of abstraction may
work for some people.

~~~
blackRust
Exactly, I think if you are a hacker you will stick with the shell the way it
is, because knowing how stuff works with "zero" abstractions is power.

Reminds me of this: <http://i.imgur.com/jqIcv.jpg>

Also I mean as a hacker, not as an entrepreneur.

~~~
unconed
I think my point is that we've all been so locked into these tools that we've
become blind as to where their failing are. I wanted to start TermKit from a
fresh slate and only slowly add bits of existing Unix to it, so I could make
sure the resulting whole still made sense.

~~~
henrikschroder
For me, as someone that does all his work in Windows and stays away from
consoles as much as possible, this entire discussion is hilarious.

I think your project is cool, it certainly is a fresh take on the console, but
the minority of people that like the unix console will be very resistant to
anything graphical, and the majority of people that prefer graphical
interfaces will just wonder why the hell you still need to do all of that
typing. :-)

The fundamental problem with consoles is that it's impossible to explore the
interface. You can only use it by knowing the possible commands beforehand.

Hmm.. Perhaps that's something you could explore with Termkit? With the added
graphical output, is it possible to show hints for what I can/want to do,
given what I've already typed? I dunno, just an idea.

~~~
blackRust
The power is in knowing the shell. You can do things quickly and do exactly
what you want if you know how to use it. No GUI can give you with the same
speed and efficiency.

The learning curve is steep, I like your suggestion of 'exploring' the
interface. I think this deserves more merit than making the shell glossy.

------
amosson
The terminal hasn't changed much in 40 years because it very good at what it
does, that is, allowing experts to _get stuff done_. One of the usability
lessons of modern computing is that the mouse is a productivity killer. Having
transitioned back to vi from TextMate, I have certainly found it to be true.

The author talks about how its a shame to give 2MM pixels to an 80 column
terminal, but from what I've seen, developers are perfectly capable opening
multiple terminal windows to view things like log files and running quick
commands. Try that on a WYSE.

While I don't think I'd ever use this as a replacement for my terminal, I do
think the "server" part of the architecture is interesting. What if you built
a native OSX app to replace finder. That is something I'd use.

~~~
william42
«One of the usability lessons of modern computing is that the mouse is a
productivity killer.»

Actually, one of the usability lessons of modern computing is that the mouse
makes you faster, but the keyboard makes you _think_ you're faster.

reference: <http://www.asktog.com/TOI/toi06KeyboardVMouse1.html>

~~~
amosson
Here is Atwood's response

[http://www.codinghorror.com/blog/2008/03/revisiting-
keyboard...](http://www.codinghorror.com/blog/2008/03/revisiting-keyboard-vs-
the-mouse-pt-1.html)

------
gurraman
This a cool project, albeit not my cup of tea. Sure, the terminals out there
need a little work, but I'm skeptical about bringing too much of the "gui
world" in.

There are, however, some concepts that are worth copying and that are in fact
doable in current terminal environments. What I would like to see is more
innovation in the world of console programs. There are lots of things to do in
terms of auto-completion, navigation and integration etc.

Take a look at ranger [1] and sup [2] for examples of new neat console
applications.

[1] <http://ranger.nongnu.org/> [2] <http://sup.rubyforge.org/>

~~~
beza1e1
"Notmuch is an answer to Sup. Sup is a very good email program written by
William Morgan (and others) and is the direct inspiration for Notmuch. Notmuch
began as an effort to rewrite performance-critical pieces of Sup in C rather
than ruby. From there, it grew into a separate project. One significant
contribution Notmuch makes compared to Sup is the separation of the
indexer/searcher from the user interface."

<http://notmuchmail.org/>

~~~
carmen
why should indexer/searcher be coupled to email files in particular, instead
of dispatching on MIME types? why should the datamodel be something ad-hoc
instead of RDF?

[http://blog.whats-your.name/post/2011/02/14/sifting-thru-
you...](http://blog.whats-your.name/post/2011/02/14/sifting-thru-your-IRC-
logs-w/-examine)

~~~
BCM43
That's something that they are working on. One example of a useful application
is a text ebook collection.

------
ianb
I played around with what I think is a very similar idea a while back:
<https://github.com/ianb/jsshell> \-- I think the basic architecture is the
same, but this is much more advanced; I never really got past the point of
displaying all output as literals.

In both cases I think this is really as much a replacement for the shell
(e.g., bash) as for the terminal. The truly fundamental verb in a Unix system
is executing something with a set of string parameters, an environment, and a
cwd, and passing stdin in, with stderr and stdout coming out. That's pretty
much everything, so there's a lot of flexibility about how you can present
that to a person -- all the stuff like &, if statements, file redirection,
shell quoting, etc., is part of the shell UI, it isn't really core to the OS
or any of the commands.

There's a lot of graphics and icons in this particular implementation, but
IMHO that's not really the important part. Taking out the statefulness of the
shell is the more interesting part to me. "cd" seems magic, but it's just
setting an internal variable in the shell. Foreground and background processes
seem core, but they are just a way of handling the inability for a terminal to
handle more than one thing at once. Variable substitution, redirection,
backticks... these are all abstractions; and they are useful abstractions, but
they might deserve a bit of rethinking.

------
Tycho
I find Unix usability standards generally pretty insane. Funny he should post
this, as on the train today I was thinking of making a program I'd call
'SmartTerm' or something which would basically be a more usable, graphically
augmented terminal for beginners (or people who just can't stand interfaces
which depend on memorization and patience).

Some things I find nuts about the current terminal is OS X (at least the
default behaviour) are:

\- half the line which you need to write in is taken up by repetitive info
like User, Time, and Directory

\- put the currend directory somewhere useful like the title bar

\- when i start to type a command, give me graphical autocompletion
automatically (unless i switch it off), along with a note/tooltip explaining
what the command does

\- after i've typed command, give me a pane somewhere which explains what all
the stupid flag options are and what they do

\- give me another pane with an audit trail in plain english of what my
commands have accomplished, and then give suggestions on how these could be
accomplished using simpler shortcuts (especially in something like Vim. give
me some help to learn the shortcuts as i work, FFS. on a GUI you look at the
keyboard shortcuts beside the menu items, and get to know them naturally. this
would also give you some confirmation that your command worked as expected,
rather than just a blank prompt staring back at you

\- let me highlight text with shift and arrow keys

~~~
ak217
> especially in something like Vim. give me some help to learn the shortcuts
> as i work, FFS. on a GUI you look at the keyboard shortcuts beside the menu
> items, and get to know them naturally.

This. I hate both vi and emacs for not having a usable menu system that lets
me browse through and learn the commands as I go.

I also think bash-completion, while a huge step forward in usability, really
should have focused on integrating command option help from the beginning. So,
in addition to a man page, each command line utility would need to bundle a
machine readable key-value list of (option, help string). Then when I type
<command> -<TAB>, it would show me that help.

~~~
jrockway
Pretty sure Emacs has menus:

<http://jrock.us/emacs-menus.png>

~~~
ak217
It does. The problem is, the terminology in the menus is completely
inscrutable (i.e. many commands are named unintuitively), the menus are poorly
organized, they have a small subset of all the commands, etc. I've never been
able to learn any of the shortcuts from the menus.

~~~
jrockway
In the end, it's your fault because you don't want to learn. Emacs does not
have "cut" and "paste", it has "kill" and "yank". They are different terms
because they have different semantics.

Enjoy programming in Notepad.

------
perlgeek
I love the idea of experimenting with graphical output on the console. I've
seen images and vidoes running on the terminal (not a terminal emulator) using
"framebuffer" consoles.

Sadly that typically only worked in full-screen mode.

If somebody wrote an ordinary terminal emulator that allowed pixel graphics as
part of the normal text flow, and created an easy API for programs to use it,
I'd be very happy.

TermKit looks cool, but I fear I'm too old-fashioned to move away from
ordinary shell in such large steps.

~~~
djhworld
I think this guy should look into implementing something like this as a
compromise.

~~~
wladimir
No, he shouldn't be making compromises at all. He's rightfully aiming at
making the shell of the future. Features to comfort people that are stuck in
their current ways can easily be backported in later, as we know how they work
since the 70's.

------
lut4rp
As much as the prospect of Webkit in my terminal makes me uncomfortable, I
think this is amazing. The terminal is probably my most used application and
any effort towards making it better is awesome.

(P.S. - Apart from this, unconed has also been a prolific Drupal contributor
and done some amazing visualization work for Winamp. Awesome hacker.)

------
tvon
This has been tried before with the XUL-based xmlterm around the turn of the
century, but it was very slow:

<http://www.xml.com/pub/a/2000/06/07/xmlterm/index.html>

Interesting to see someone pick this up again.

------
Symmetry
There's actually a lot that can be done to improve current shells even without
breaking the current set of abstractions and tools:
<http://en.wikipedia.org/wiki/Fish_shell>

------
balakk
On windows have a look at <http://poshconsole.codeplex.com/>

Same idea, with powershell as the base.

~~~
unconed
Interesting. I stayed away from powershell because it does the opposite of
what I want to do: it makes the shell more like a programming language, and it
still limits the output to text.

Thanks for the tip.

------
mhd
None of the examples really sound all that exciting. I see the Unix shell more
of a text file manipulation toolkit, so apart from some corner cases I'm not
sure if adding MIME types etc really would add much value for the usual tasks.
If you're adding too much structure to things, you might as well go all the
way and base everything around a programming language or framework (cf.
Oberon, Powershell, Lisp Machines).

I agree that emulating a terminal from the late 70s isn't exactly the peak of
programming. Character-addressed terminals are just another way to get (cheap)
WIMPy GUIs.

------
technomancy
Ironically enough, this reminds me a lot of eshell, the shell implemented in
Emacs lisp. Since it runs in a rich environment, it can augment a lot of
standard unix functionality with really useful features, and you can extend it
in a language that's not insane.

For example, grep/find results are hyperlinked, you can pipe commands directly
to buffers (or even lisp functions) rather than just files, and such. In fact,
now I'm tempted to add the ability to cat an image and have it display inline;
should be pretty easy to implement in elisp.

------
wickedchicken
As far as I can tell you have to rewrite all your applications to use this. So
he's not really advocating "a cool new terminal," he's advocating a "new Unix
programming toolset, with accompanying terminal, to replace the BSD/GNU
tools." This is great, and I wish you all the best of luck, but it looks like
you're just rewriting Applescript.

Also, the reason Unix tools don't toss around JSON/XML/MIME is for sheer
simplicity. It's a zen thing, something you OSX guys wouldn't understand.

Catting a png and getting a picture is nice though.

~~~
ernesth
Instead of 'cat image.png', if I want to see the image, I just 'image.png'
(zsh's "alias -s" magic).

------
CMay
I've toyed around with similar concepts, but went the way of trying to middle-
man the input and display of a standard console instead of trying to recreate
one. Admittedly that creates some limitations to how integrated things can
look without extra work, but it allows for normal interactive programs and
really only enhances what was already there. Plus there's the added benefit of
being able to run commands even while something interactive is up.

In any case, these kinds of hybrids are inevitable due to the vast room for
improvement that exists in desktop and system apps combined with how powerful
the web standards have become for UI and interactivity.

Really though, while I think TermKit is a decently executed attempt at this,
it alienates some of its audience for obvious reasons. It completely throws
away the charm of a shell with visual style choices and breaks powerful
features that people expect. That's fine, because even with those departures
it can suffice as a casual mode with certain conveniences for times when it
makes sense.

Visual styles can be fixed or customized, so that's just shortsightedness by
others.

As far as expected features like interactivity and whatever else people feel
TermKit lacks, it seems like any hybrid terminal that takes this route should
really try to implement a quickswitch that lets you fade between a rich
terminal and a standard text console, already at your working directory with
the same permissions.

Sure, people could just task switch to another running console, but that
segments the whole experience a bit more.

------
wladimir
I just looked at this through the github link. Looks very nice and useful.

Too bad it's very much bound to MacOSX/Cocoa, so this kind of rules it out as
general nextgen UNIX/Linux shell.

~~~
bruceboughton
From the article it sounds like most of the heavy UI is implemented using
webkit and HTML/CSS/JS. Wouldn't this make it reasonably easy to port to *nix?

~~~
wladimir
I have no clue, I looked in the github repos very quickly and saw all kind of
scary .m files and I gave up :)

If it's mainly HTML/js/webkit based then it would not be hard to port it to a
portable window toolkit such as Qt4 (which has a QWebKit widget...).

~~~
mikemaccana
Doesn't the article say it's TK? Which means it's already got X bindings.

~~~
unconed
TK just means TermKit, sorry.

------
tlrobinson
This has a lot of great ideas, and I like the idea of an enhanced terminal in
general, but I think it goes too far. Having to reimplement a large number of
commands to support this concept of separate view and data streams is complex.

A few ideas I'd like to see integrated into an existing shell/terminal in a
backwards compatible way:

* Syntax highlighting/tokenization of the command as you type. Show the different parts of the command you're typing: the executable, the arguments, the pipes, the IO redirects, shell constructs like loops and conditionals, quoted strings.

* Maybe command-specific syntax awareness like highlighting the flags and file arguments differently, regular expressions for sed/grep, awk syntax, etc. This would require descriptors for each command, similar to how autocomplete works?

* Enhanced output formatting, like the clickable paths, displayable images, etc. But rather than modifying/rewriting the program, have a way to describe how to display the output of certain commands. The shell should be able to figure out what the final command in a pipeline is, right?

* Detect and display binary file formats based on the content rather than the filename so support existing commands.

------
swah
Post about TermKit: <http://axisofeval.blogspot.com/2011/05/termkit.html>

------
rglover
As a UI designer, even though I've just begun working with terminal, I can't
say I like this too much. Don't get me wrong, it looks GREAT, but much as I
expected, it goes against a lot of ideas and based on some of the comments,
strips a bit of functionaity (a huge no no). I think Steven's intentions are
solid, but he's sort of playing with fire on this one. Cool idea, though.

~~~
adambyrtek
Of course he is playing with fire, that's the only way to do real innovation.
Remember that this is just a proof of concept, and a very compelling one.

------
andrewcooke
it's curious this is on the front page at the same time as oh (or was that on
reddit? - can't seem to find it now). <https://github.com/michaelmacinnis/oh>

both allow the shell to use structured data. i like the idea of using json
myself (not that keen on the gui parts of the implementation, but moving pipes
to something with more structure seems like a good idea). did plan 9 do
anything similar?

~~~
benatkin
Here's the link to the comments:

<http://news.ycombinator.com/item?id=2559361>

------
skrebbel
Only his response to the AVS question in <http://acko.net/blog/on-
termkit#comment-4240> made me realise exactly how powerful this premise is.

TermKit could become my OS of choice.

------
StuffMaster
>monospace text just doesn't cut it anymore

Maybe in _your_ terminal world, but not mine buddy.

~~~
qjz
Seriously. But I wish all fonts included a monospaced variant. Why shouldn't I
use Helvetica in my terminal?

~~~
romland
Did you even _try_ to find it?

Google "helvetica monospaced".

------
sehugg
Very cool. I'm always amazed at how much one can do with a properly composed
pipeline and a Makefile or two. The power of pipes + the interactivity of a
spreadsheet -- that's what I want in my next gen shell. I'll be interested in
seeing how this experiment plays out.

And I do see it as an experiment, not a threat to our way of life. I like to
think that the UNIX command-line environment is a local minimum.

------
mtogo
My god, this looks terrible. There's a reason we're still using text terminals
from the 70s-- they work!

I sincerely hope i won't ever have to work with this.

------
adnam
This is interesting, but I have doubts. He wants to fix the terminal by
'separating the "data" part from the "human" part'; in practice, using
separate visualizers for human display. This puts me another degree of
separation away from my raw data and forces me to trust the accuracy of the
visualizers.

~~~
unconed
You already trust the accuracy of your visualizers: your eyes. Is it space or
a delimiter? Is that a quote or a backtick?

------
jesheit
TermKit could really help unix overcome the problem of discovery.

On the command line it takes extra steps to discover the switches and
arguments that a given command presents. It's easy to miss a specific
incantation that will bring forth the full power of a given command in a given
situation. Git, for example, has an amazingly rich command. It's hard to
discover what you can do so most people end up using just the few commands
that they absolutely need.

Just as TermKit offers a selectable list of directories when one types a path,
it would be great if it could provide a structured way to build commands
invocations, that presents options and perhaps help content as you go.

In addition to helping newbies dive in and get stuff done, it would help more
experienced users continually advance their knowledge of how to get the most
out of the tools they use.

------
chalst
Some interesting ideas there. He doesn't link to discussion of similar
projects: I was reminded of Commander S:
[http://www.deinprogramm.de/scheme-2005/05-knauel/05-knauel.p...](http://www.deinprogramm.de/scheme-2005/05-knauel/05-knauel.pdf)

I've not been able to build Termkit yet, mind.

~~~
unconed
Shouldn't need to build it, there is a zipped .app included. You do have to
build node.js though.

------
agentultra
I'm just curious if he has to re-write essentially every unix tool in
javascript.

I can't really say whether most unix developers would appreciate this. I don't
like it and I exclusively use tiling window managers, xterm, and emacs. Though
if I wanted fancy features I might try rxvt-unicode or some such.

------
pnathan
This is interesting and a cool proof of concept. I don't believe that, as you
show it, it is something I'd want to live in.

I virtually live in a full-screen emacs (on CLI or GUI). Emacs provides a
somewhat nicer shell world than straight up Terminal.app. Emacs has copy &
paste, a fully editable window display and its own command history.

Why do I bring this up? Because I feel that your application as currently
demoed is not going to help me. I don't want to see GUI icons in general.

What I do like is your connection to the OS display layer. The ability to
render out a PDF-inshell is pretty nice. Without having to go grub around for
the right configuration, I can't just go "load foo.pdf" and have it pop up
automatically.

So I really look forward to see what kind of cool explorations you do.

------
yason
Can't really say this or that about the project. It _looks_ cool but I have no
idea whether the user interface would lessen the friction between myself and
the computer; it might just as well increase it.

But that's okay. We're not supposed to decide whether the prototype points to
the right direction or not; we're just supposed to rant and ramble a bit about
it.

However, the question of whether this turns out to be a good idea will be
evident when and if TermKit delivers. In this context it means that TermKit or
some of its derivatives turn out to be actually more useful than the standard
Unix shell.

The indicator would be that instead of a traditional Unix shell, people start
using TermKit in order to get more things done more easily and in shorter
time.

------
mikey_p
Excellent shortcut for previewing files from the terminal:

    
    
      #!/bin/bash
      qlmanage -p "$@" >& /dev/null
    
    

Opens any file in Quicklook, ctrl-c to close, or use the mouse. If you want it
to stay open, just add final &.

~~~
unconed
Added to my todo list. Thanks, didn't know about this one.

------
tjarratt
I really hope this guy gets hired by Apple. There are some really great ideas
here.

------
mixmastamyk
Looks pretty cool. The problem with the vast majority of these 'rethinking'
projects though is they never get finished. That's the hard part.

The classic unix toolset remains because it is finished--that is most major
problems and workflow have been ironed out.

Unfortunately I'm time-constrained these days so I'll give it a go when it
version five is out and all major issues have been addressed and ported to
Linux. For now I'll use fish locally and bash over ssh on my servers. Also, as
I can use nautilus to manage and edit remote files using gvfs. So I've already
got most of what the project offers working today.

------
bdunbar
It looks like you've re-invented Midnight Commander, which was a re-invention
of Norton Commander, which was probably a re-invention of something else.

Which is a good thing! I look forward to downloading and trying it out.

------
risotto
Awesome project.

Browser technology is on a tear recently, and terminals are ripe for
innovation. For a newborn project, this is an impressive mashup.

The number of dismissive people in this thread shows how disruptive this idea
is!

------
arnoooooo
I tried to start a discussion on reddit with a very basic version of this
idea, which was met with a lot of criticism.

In the end, I'm thinking it would be enough to have espace characters : for
embedded graphics, and for some kind of terminal hyperlink. An exemple is file
names in grep listings, which I would like to be able to click to get the
filename pasted on my next command line.

------
joe_the_user
I like the overall idea a lot and am working on something vaguely related
(though more like Quicksilver/Gnome-do).

I doubt that a modern approach is going to be able to satisfy the entire
historical legacy of the Unix terminal and it probably shouldn't. Everyone
who's happy running vi in an ordinary terminal should probably continue to do
so.

------
bostonvaulter2
I'd like to see it be able to run a program in the background with the -h flag
or --help flag to find at run-time what the available options are to help
auto-completion. This way it would be able to support even programs that it
doesn't know a priori.

This looks like a fantastic direction to experiment in. Kudos to the author.

------
blackman
Looks really good (haven't tried it yet though). The concept is great. I'd
like to see some TextMate/CommandT style functionality for file and path
completion (I've been thinking cd'ing around in shells has been cumbersome
ever since trying commandT).

Some other inspiration could be taken from zsh autocomplete.

------
senthilnayagam
awesome, my kids and the touch generation would now start using termkit as
their terminal in this natural way

------
jiyinyiyong
主意很棒,十分佩服作者所做的工作,之前我也有过类似的想法

为了不说错太多,我不知道这里是不是允许用中文?

.

图形化取得的成功有目共睹,而偏偏终端保持纯文本的简单

从学习linux的经历和这么久接触互联网看

.个人用户接触到的图形视频信息远多于文字

命令行有着天生的优越性,图形界面的鼠标操作完全显得累赘

同时另一方面命令行却难以控制界面又显得苍白了太多

即便是掌握了多数常用的快捷键也难以足够高效

对于一个整天上网并且忙碌于控制各种信息的人来说

.不能获得快速的操作方式是非常纠结的一件事情

.

在思考当中我期待着命令行可以和图形界面深度的结合

.就像是语音搜索和移动平台漂亮的界面结合那样

显然,命令行更精确,能做更多的事情,效率更高

期间关注了Ubiquity和Vimperator这类在浏览器的实现

.从效果上说,功能实在不足以让人将日常的操作迁移上去

.总归是一个好的尝试,我期待这更多

.

所以我认为作者的方向与上文两个插件走在同方向不同的路上

最终也许图形与命令深入契合之后便利更加明显

.也有可能此类产品难以被普通用户接纳

有点像从js console里面直接抓去和操作界面元素的意思

我想那么的未来总是会被不同的各种创意实现

.最终图形和命令的合作亲密无间

.

youtube的搜索参数也有点这意思

我附上Ubiquity和Vimperator的视频吧

[http://www.youtube.com/watch?v=r54O47ZR64A&hd=1](http://www.youtube.com/watch?v=r54O47ZR64A&hd=1)

<http://youtu.be/XI1XwdtmtQY?hd=1>

------
Rhapso
It is pretty (and I want it for linux so I could use it!), but I think the
real useful idea here is the separation of data out, and display out. If we
could have that on a regular shell it would add a lot of usability. For this
idea alone, my hat is off to you sir.

------
ytart
The problem with this fancy terminal is that the standardized tools, like cat
and ls get abused in very bad ways...

What's the problem with ImageMagick's display for example? Or defining a new
command that does pretty printing of images, like, say pls.

Don't fuck with our tool-chain buddy!^_^

------
tezza
Great. Looks awesome and is much needed.

It should be possible to map the output for the Current Working Host too.

So:

    
    
      home> ssh Server1
      Server1> ls
         server1file.bin
    

that

    
    
      server1file.bin
    

should be mapped to

    
    
      scp Server1:server1file.bin

~~~
unconed
I'm not sure what you mean. If you like, you can describe your idea in more
detail and open an issue on github:
<https://github.com/unconed/TermKit/issues>

------
planckscnst
The author talks about the hazards of parsing text streams, then talks about
parsing ls, which is impossible to parse because there is no way of
differentiating a newline in a filename from one that delimits the end of a
line of output.

------
swift
This is just fantastic. Great work. I look forward to see how it evolves
further.

------
dadro
Amazing work. This kind of API has potential to be a real game changer.
Imagine what this style interface could do for things like Image, Audio and
Video processing. Can't wait to watch see this progress.

------
rbranson
This will replace the terminal as much as the microwave replaced metal over
fire for cooking or as much as synthesizers replaced real instruments in
music.

~~~
sehugg
Have you listened to the radio recently? ;)

~~~
rbranson
Off and on in the car, but that's irrelevant. I'm not claiming every
technology is irreplaceable, but that not all evolutions or supposed
improvements of technologies REPLACE their predecessors.

------
hellweaver666
Hmmmm. It's pretty, but sort of limited at the moment. I think it could be
used sort of like training wheels for unix newbies.

------
TomLimoncelli
OH MY GOD! THIS GUY WANTS ME TO CHANGE THE WAY I WORK!

I"VE BEEN WORKING THE SAME WAY FOR 20 YEARS

YOU CAN"T MAKE ME CHANGE!

CHANGE SCARES ME!

20 YEARS AGO MY TERMINAL DIDN"T HAVE LOWERCASE, COLOR, OR WINDOWS. WHY HE WANT
ME TO CHANGE!!?!?

(Damn, I've never seen a group of people so change-adverse and closed minded
about trying new things as the software developers that are in the business of
making new stuff! Geeze! Download it and give it a try before you post a
comment!)

------
swlkr
Wow this is awesome. This project basically just showed me everything I never
knew I wanted.

------
AdamGibbins
Awesome highly recommended Linux terminal, allows GUI splitting and has very
almost 100% key-shortcut coverage: <http://www.tenshu.net/terminator/>

------
sunkencity
Inspiring! And gorgeous look and feel to the site.

------
samlevine
More proof that people who don't understand UNIX are condemned to reinvent it,
poorly.

~~~
unconed
People keep saying that, and then fail to tell me any solid reason why I'm
wrong.

------
bmaeser
one word: genius!

------
gcb
it kind of defeats it's own purpose.

cat a.png -- show the image in a tiny terminal, but I have a billion pixel
screen.

why not just open it on the image viewer window?

you advocate this even for editing plain text in vim!

think that if you had learned to use X your days would be more productive...
maybe not as cool...

