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.
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.
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?
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.
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.
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.
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
$ 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.
So putting that in.