[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?

[wickedchicken]

> wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $?

You can already do this. http://www.faqs.org/docs/Linux-mini/Xterm-Title.html

> Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do)?

This can probably be written as an extension to bash/tcsh/zsh to use the pop-up completion facilities of vim. If you want nice webapp-looking ones, you might be able to get away with terminal escape codes and use a perl script (this is how rxvt lets you click on http links automatically).

> can the result not be folded into a single line showing the summary, that I could expand if I wished?

An interesting point, and I was going to counter with a small one-liner using 'tee,' but I couldn't think of a good one quickly that does what you really want: 'auto-collapse.' The problem with this is that often with giant lines of output you really only want to look at the last few to see what happened. Otherwise your output is typically some kind of streaming log (you do not want auto-collapse for this) or a poorly written program. "walls of text" suck and are usually an indication of something you expect to have a lot of output (looooong makefile) and can do a less accordingly, or an unexpected error. If it's an error you want to see what it is, so you're going to click on the 'expand' button -- an extra click every time on an all-typing interface kind of sucks.

[tezza]

I also think this is a great implementation of a useful idea.

Why all the haters? Surely the next step is a MIXED-MODE console where you can have both the power features shown, and a simple mode for the die-hard traditionalists.

Again... stirling work and I'm looking forward to it.

[wladimir]

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

Yes, that's possible. Webkit embeds JS, and you can do the craziest of controls in JS, communicating with your process through JSON packets (at least, that's how I understand the article). This would need some extension mechanism at the side of the shell, though, but that's not rocket science.

[Tangaroa]

Ditto to that. I admit predisposition to liking Termkit because I also had a similar idea in the past and I had neither the time nor talent to go anywhere with it. Kudos to this guy for producing something that looks like a very large step in the direction of improved usability and a potential step towards improved performance if programs can be made to pass each other common structures without needing to serialize and reparse the data until it needs to be seen by a user.

In addition to the frontend and pipe changes, I also imagined changing the way files are accessed. Some subsystem could put indexes and attributes on certain data files so you could run something like:

$ query --tsv login, uid, name[last='Smith'] < /etc/passwd > mysmiths.tsv

or:

$ cat /etc/passwd[@uid=0]@login

and you would get the desired set of information without needing to write potentially buggy regex scripts. If there was a new type of file that you wanted to get data from in a few different ways, you could write only one buggy regex script to use as a filter and then query the file with the shell's normal query methods to pull down any information you might need. In the example of pulling users from a file, the shell could know from the attribute metadata that you are looking at a list of users and it could show the results as widgets that you could right-click to get the user's properties.

This all implies rewriting every utility in the system to accept recordsets instead of text, adding custom code for every different targeted data file, and making sure it all works with existing tools that have not been converted yet. That could be difficult, or at least time-consuming.

[unconed]

I just saw this: http://jsonselect.org/#tryit

So putting that in.

[l3vitat3]

man, if you had to operate daily hundreds of files you will forget quickly about drag'n'dropping, scrollbars and all that annoyances. about the popup is useless on a keyboard controlled interface as the number of keystrokes needed are the same. the problem you have, is that you think that your terminal application is badly-glued into your graphic system, when in fact your graphic system is badly-glued on terminal applications