I'll answer with a Koan, it's author long forgotten (if you know him, do tell me his name!):

A UNIX wizard hears cries of torment from his apprentice's computer room where the apprentice is studying, and goes to investigate.

He finds the apprentice in obvious distress, nearly on the verge of tears. "What's the problem?" he asks. "Why did you cry out?"

"It's terrible using this system. I must use four editors each day to get my studies done, because not one of them does everything."

The wizard nods sagely, and asks, "And what would you propose that will solve this obvious dilemma?"

The student thinks carefully for several minutes, and his face then lights up in delight. Excitedly, he says, "Well, it's obvious. I will write the best editor ever. It will do everything that the existing four editors do, but do their jobs better, and faster. And because of my new editor, the world will be a better place."

The wizard quickly raises his hand and smacks the apprentice on the side of his head. The wizard is old and frail, and the apprentice isn't physically hurt, but is shocked by what has happened. He turns his head to face the wizard. "What have I done wrong?" he asks.

"Fool!" says the wizard. "Do you think I want to learn yet another editor?"

Immediately, the apprentice is enlightened.

While text editing interfaces could be more polished and modern--the underlying problem that causes your dissatisfaction is the text. Storing code as text is an evolutionary dead end. Storing code graphs in text requires the use of plaintext names for graph references, which binds logic and presentation together. The gap between the goal-completion logic a user comes up with and how they turn those mental instructions into plaintext is an unnecessary jump--an encoding--that produces no end of trivial but infuriating miscommunications.

Storing code as pure structure (not XML or anything silly, the serialization is trivial) avoids a huge class of artificial problems we've had to deal with since the dawn of compilers, due to the disconnect between human meaning encoded in plaintext and machine parsing.

Visualizing code as text--text as the primary view in the MVC, complemented with colours and annotations and hyperlinks and hints--is extremely useful. What we really need is a structural editor with the familiarity and ease of use of a text editor. But that is a hard problem, and more polished text manipulators are a nice stop-gap in the meanwhile.

Reading the introduction, I was really excited. I fully agree with the premise, but the proposed solution seems inadequate. Putting shell in an editor, adding hidden metadata, and making the output hyperlinked just don't feel radical enough.

Also, some parts of the proposal are very vague (description of MVC), while others are extremely specific (whole paragraph about an obscure Unicode delimiter), which makes it hard to get the big picture. That said, improving the terminal is a really challenging and important problem, so I'm glad there are people thinking about it.

The idea of using an obscure unicode code point to indicate the start of metadata, in the expectation that nobody will use it, is probably self-defeating. As soon as that's is use, there will be a reason to use that obscure code point (in documentation, in code, etc), so you will still have to deal with escaping it.

I wholly agree that splattering chrome over a terminal isn't the best way forward. Emacs shell mode gets me all?most? of the way to the interface posed as the solution (text editor as interface to terminal). Being emacs, I am sure I could finish up the proposed solution with "a few lines of elisp".

And I don't think it's the solution. These issues are spawned deeper in the design. Multiple streams of information are being spawned, and must be handled sanely: pipe redirection starts breaking down here because it's a line - what's needed is a graph of management that's able to handle different cases and join back for the next approach.

One approach might simply be to develop a higher-powered programming language environment that calls directly into the system.

Sometimes when I have text files open I want to be able to run command line tools against them. I know I can go write a shell script but sometimes I want to write grep against my inbox or against all the windows I have open at the time. I want to be able to high lite some text (possibly in more than one window) and then have a transparent shell appear that lets me write expressions to work with that text, like sort it in place. Often I have to move things into and out of text files, spreadsheets,databases to be able to apply all the tricks that I like. I wish those tricks could just appear and work with what I'm looking at.

I am skeptical about total reimaginations, and when I read this I started to take it as one of those airy "Dude, someone totally revolutionize this for me..." posts, but then I hit:

I’m working on this in my spare time, starting with...

and now I'm curious to see what the author comes up with.

There's just something about an actual tool, no matter how prototypical, that improves the discussion of new tools.

You can and should separate view and controller. Imagine if you could spawn windows at monitors, and then have things display on them via pipeline.

You might type into a tiny window on one monitor that never loses focus, but sends graphs and text and streams to these windows.

There's no reason that the place you enter text should correspond to the output display, and a lot of value to be had by separating them.

Imagine being able to plug display consumers into a port so that you could do visual demos.

Here's my six-year-old rant about how crufty terminal technology is. It's not a visionary re-imagining of terminals like this article is, but personally I think that one of the biggest barriers to innovation in terminal technology is that the current stack is so incredibly baroque and difficult to program or extend elegantly.

http://www.advogato.org/person/habes/diary/6.html

There are some interesting ideas here. One thing that occurred to me while reading it was using a message queue to implement the pipeline functionality. I've been interested in Apache ActiveMQ/Camel for a while now and excited about some of the things it can do. With that model, each 'line' could have it's own set of headers, allowing for transformation by aware tools, but transparent by default. This would also blur the line between running commands and having background filters. It would also work nicely over the network.

I did some experiments with clojure/camel at one point, and came up with stuff like this:

(defroute context (from "file:/home/jw/scratch/inbox?noop=true") (to "file:/home/jw/scratch/outbox")) ; from http://codeabout.blogspot.com/2010/06/using-apache-camel-fro...

Which is basically a continuous file copy. I could see different flags for "do now and exit", "do at HH:MM:SS", "do until I tell you to stop", "do when system is idle", etc.

The author confuses a terminal with a shell running in a terminal.

I'd like for my terminal to be able to open a stream of html in my web browser. Use case: running `man blahblah` in a ssh session opens a nicely formatted page in a local browser window.

I'd like for my terminal to be able to open a stream of text in my editor, and accept a stream of text back from my editor to save somewhere. Use case: running `sudo -e /etc/blahblah` in a ssh session allows me to edit the remote file /etc/blahblah in a local text editor, and save my changes back.

How about something like Archy? https://en.wikipedia.org/wiki/Archy#Features It was never polished but you can still play with an old (windows) build: http://users-www.wineme.fb5.uni-siegen.de/home/SebastianDrax...

Edit: or for a gui, something like Enso (for the whole OS) http://humanized.com/enso or Ubiquity https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_... (for the browser) Both are abandoned open-source projects with a lot of the hard work already done (the internationalized parser in Ubiquity is very nice).

Acme seems to come pretty close to the author's idea, combining both a terminal and an editor.

I've been thinking about a user interface for a long time. One that, leverages the graphical capabilities of the browser and the linguistic capabilities of the command line.

The two enhancements over the command line that I envision are the discoverability of commands and the ability to select the output of commands. So what you'd is an Enso/Vimperator like command interface where the output would be rendered as an 'object' or list of 'objects'. Each output object would be selectable and able to be used as input for other commands able to digest them.

You can sort of do this now with the command line but there are a few issues. The first is the inability to render graphical results in a terminal. The second is having to now something about the output of a command apriori before piping to the next command. Finally, it is difficult to know the commands available to your fingertips on the $PATH.

The more I meditate on a system like this the more I think it would be wildly productive because a wide host of problems can be solved with this single workflow.

COMMAND -> RENDER OBJECT(S) -> SELECT OBJECT(S) -> COMMAND -> ...

While perhaps off-topic, I'll chime in with an anecdote in remote computing I had this past Thanksgiving. Short version: If you're an emacs veteran, tramp is the ssh version of ange-ftp. Long version: was down in the San Diego area for Thanksgiving and my development environment (Linux) was up here in San Francisco. Had ssh and VNC access to my Linux server in SF, however the latency was still pretty bad making VNC just barely usable. However I had access to a Mac in San Diego with MacPorts X11 emacs installed. I could then run emacs locally and use tramp to transparently access my remote files via ssh just like the old ange-ftp package. Another benefit is that running a shell within emacs with current tramp buffer will automatically ssh to that same server. Tramp would also work with version control (in this case svn). So the big wins here: 1) local editing speed. 2) efficient network communication (only the file data is transferred) 3) shell and version control support 4) can still use emacs.

YMMV.

http://www.gnu.org/s/tramp/

I think they're seriously misunderstanding both TermKit's goal and the difference between running commands and editing text.

TermKit, for instance, is not just a widget-infested terminal. The core idea behind it is what >50% of this post is about: data interchange that's not un-tokenized text that you have to `awk` to hell and back to do basic things.

Meanwhile, text editors do two things incredibly differently than system-control interfaces: they edit blocks of text, and they can un-do almost every action. Next time you `rm` something accidentally, try pressing `u`, and see if it comes back. Or rewind that `drop database production;` your cat typed into your ssh session.

I also don't want Bash to be my editor for similar reasons why I don't want to manipulate my filesystem with Vim - I rarely need to enter visual select mode when composing something in Bash, and Vim is poorly-suited to piping streams of text through multiple programs.

Some months ago I tried to improve shell while keeping all it's features. So i made webkit-based terminal emulator (pseudoterminal; like xterm) with special esc-sequences to turn on html output (in a console, yes). Screenshots: https://github.com/shepik/wkterm/#readme

This sort of reminded me of TermKit, which I think is still on Github... but sort of stagnant the last time I looked.

The beauty of Unix is its simplicity.

This made Unix so reliable. If you want to write a beautiful terminal as _addon_ I have no problem with that. But I would not accept a _replacement_ of the old fashioned terminals. Because they are so simple, they just work.

If you want to waste less time reinventing the wheel, why not try a Lisp-machine style terminal system with "live" objects (presentations)? It's proven to work, and many people liked it more than a terminal-based command line. Use polymorphic lines (http://groups.google.com/group/comp.lang.lisp/msg/02782906f6...) to get a very concise, powerful presentation. OpenDylan (http://opendylan.org/) and its IDE/editor Deuce implement these ideas.

I agree that there is too much focus on "intuitiveness," but I'm neither a programmer (I'm working on it) nor a sysadmin, and I'd like a more robust user interface too! I have a lot of work to get done, and I'm willing to learn a different set of interface axioms than the ones we've been working with for the last few decades.

Here's the beginning of my thinking on the subject: http://blog.byjoemoon.com/post/9325300749/a-different-kind-o...

It's great to hear other voices in this discussion, though!

This is text editing in OpenGL: http://www.youtube.com/watch?v=2O5DJTOy6EA I'd like to have such a terminal.

iTerm2 already has the feature where you click on a filename and it opens the file. If you're running a newish iTerm2, give it a go: do an ls, then command click.

I've called it Semantic History. It also let's you drag files out of the terminal as well. Old video walkthrough: http://vimeo.com/21872771

It does not require any special ls. As long as there's a legit filename, it should work.

I find the article a bit confusing. Given this statement:

In addition, the keyboard is often more effective than the mouse for our work, since instead of floundering around in nested menus we can just type what we want. However, it’s worth noting that we don’t avoid the mouse because it is slow — if one wants to move the cursor to an arbitrary location elsewhere on the screen, one can often do so faster with a mouse than a keyboard. The problem is the transition from the keyboard to the mouse. It’s an expensive context switch, which should not be done lightly.

I don't really understand the following:

We then add syntax highlighting and hyperlinks, so you can easily navigate between man pages, or click on a grep result to visit that line in a file. Clicking on a hyperlinked directory in a file listing would reveal the contents of that directory in a nested list, slightly indented; clicking on a file would open it in a new tab.

Too much clicking for my taste.

Could someone try to distill out some sort of concrete proposal from this? I had trouble understanding what he was implying.

Kind of off topic, but this article just reminded me, I was thinking how nice it would be for a linux distro to be made for programmers. Bundled with every bit of programming language (from c to hakell and back), the standard editors with their syntax highlighting (the .vimrc already set up a little), cool special tools that maybe only serve a special purpose (stuff like gnu radio..) I was just thinking it'd be nice to have one big package, a here ya go, have at it, kinda linux. Maybe even with some alternative (but vetted) how-to documentation. For some reason I just can't get used to the flow and syntax of Man pages... And it can leave out lots of the fancy gui sidebars and stuff (not sayin get rid of the gui, just dumb it down, I'm here for the terminal, and maybe some IDEs.. maybe).

This is one of the rare delightful articles. I came to understand, after 6 years of non-programming work, and now back in front of the console, that what I like the most is the freedom that the shell provides and the room for creativity when accomplishing a task in a readable composition of tools in one line.

Certainly the provided successors of the Bourne shell might be more elegant. Certainly when piping data through several tools needs often transformation of the data representation to match the required input format. Sometimes the transformation uses different principles (regular expressions, shell wildcards, awk, sed, ..) which pollutes the logical flow of problem resolution. But I came to the conclusion that despite not being optimal, this data transformation noise holds information that, when reading or when needing to explain to others, helps to understand, or maybe remember the data model from the source to the sinks. However I believe, more uniform but more universal data transformation techniques would be a progress.

Until now this comment is more about shell than terminals, but for me, these are the biggest advantages of working on a command line - freedom and creativity in the usage of available tools.

Now, to come closer to the terminal aspect.

I am a typing fan. I went through hell when moving from Germany to France and having to re-learn a new keyboard layout - none of the both layouts are good, but if you are used to one it is very annoying to get to used to another. After having had some missions in other countries with different keyboard layouts, I found a solution, that is in line with my philosophy of using typing tools: Learn US keyboard layout, to the point to use it blindly without needing letters on the keys - it is installed on all OSes in all countries. At home use the extension US International with AltGr dead keys - I can now write all German, French, Turk and many other Latin based accents with a single layout. When in mission at a customer I ask if in the open session I can switch to US layout (if needed) - until now there were only some raised eyebrows, but no objections. And at least for ThinkPads you can order them with US layout, even with the € sign. So for keyboard I tackled the problem.

For text editors I resolved the problem already 10 years ago. I use VIM. VI is on all UNIXes, VIM is on Windows (I did not yet have to work on Macs).

On the UNIX shell the first thing I type is: set -o vi Like this many VI shortcuts and commands are at the command line.

One quote in the article made me smile the most:

"... However, it’s worth noting that we don’t avoid the mouse because it is slow — if one wants to move the cursor to an arbitrary location elsewhere on the screen, one can often do so faster with a mouse than a keyboard. The problem is the transition from the keyboard to the mouse. It’s an expensive context switch, which should not be done lightly. ..."

Yeah, this is the reason I use a track point instead of a mouse. Nothing to care with you, takes no space and you don't have to lift your hands from the keyboard. The only problem is the craving when having to sit at a customer at a keyboard that has not track point - I find myself sometimes searching for it with the fingers until I realize that I am not on my ThinkPad. It is a shame this device is disappearing on most computers.

At last: I think what unites the aficionados of the command line is the choice to spend more effort and time in learning tools which are more difficult than their alternatives (mouse vs. track point, command line vs. GUI, ten finger typing vs. two finger typing) at the beginning but pay big times off in efficiency in the long run and as a plus give the pleasure of creativity and freedom.

I encourage the author of the article to progress with his ideas! We absolutely need innovation in this space. It is just that the bar is huge because of all the tools we became used to.

> "We then add syntax highlighting and hyperlinks, so you can easily navigate between man pages"

GNU info?

This article appears to be functionally describing emacs.

I'd be 90% satisfied if we just got rid of termcap and friends.

Let's just replace escape codes with some kind of markup language (or s-expressions or whatever).

> our primary interface emulates a DEC VT100 terminal from 1978

Huh? I didn't know the DEC could run software like Visual Studio, Explorer and TortoiseGit.

Whether you use an interface from the past or not is entirely a choice. Many developers apparently prefer it, and that's fine. I don't prefer it, so I use tools with a rather modern and well-designed interface, tailored towards developers.

Please don't forget that the terminal should be useful to just get work done without programming. It's also all designed to have a human interface - all the output can be grok'd by a human and not some complex tool or parser. This is what prevents things from just magically working and forces us to come up with hacks to pipe and grep and cut pieces of data to do what we want.

If you really want to "reimagine" it, throw out the box and make a new one. If you redesigned all the standard unix tools to have a universal API and added hooks for each function they contain you could just specify a workflow to execute and the tools would figure out how to transmogrify the data internally. So for example:

  rehooliginator --store=val1 --filesystem=/proc/cpuinfo --rowname='model name' --match='([[:digit:].]\+)GHz' --store=val2 --filesystem=/proc/meminfo --rowname='MemFree' --match='([[:digit:]]\+) kB' --store=val3 --cmd=ps --fields=rss,comm --sort=rss --match='java' --field=rss --sum --math='$SUM*1024' --store=val4 --cmd=vmstat --samples=5 --field=cpu-idle --avg --output="Stats:\n\tCPU: $val1\n\tFree Memory: $val2\n\tResident memory used by Java: $val3\n\tCPU idle time: $val4\n"

This is obviously not getting away from the 'old school dynamic' of a fake terminal, but it does remove some of the need for it when we have tools robust enough that the terminal doesn't have to be as user-friendly as it is. You could combine a tool/framework like the above with a text editor to write multi-liners, sample the output and execute them on the fly. Build in hooks to execute commands over an ssh connection - or even gather output from various hosts at a time - and you could automate sampling your whole network from a one-liner.

For a "friendly interface" I think a simple tree view file browser would work nicely. So basically an "explorer"-type app with an embedded text editor and output window to let you explore a system rapidly and also automate tasks on the fly. Hell, you could build an IDE or other friendly GUI to build your query tool's arguments using quick mouse clicks.

Eshell (The Emacs Shell) is a lot of what the original post already describes in terms of power: http://www.gnu.org/software/emacs/manual/html_mono/eshell.ht.... Too bad it isn't being very actively developed anymore.

undefined

While I like the terminal... I don't want to be one.

Best Ivo

undefined

"And we, the users, play along, pretending our machine is a video terminal presenting a grid of ASCII characters in all of 256 colours. This is ridiculous."

Not everybody uses their terminal to churn out HTML pages and add 'Nyan mode' to our 'newly discovered' emacs program. For those who do that, just buy a Macintosh or whatever is this week's hip flavor of Best Buy PC. Otherwise, use a language that doesn't require >256 different colors to be represented meaningfully.

"Typography is the future"? Thank goodness X.org/XFree86 has supported custom fonts since the 1990's.

"Opening a man page would scroll gently to the top of the page, letting you scroll down and read, or search through it as you would any text"

See: MANPAGER.

"We then add syntax highlighting and hyperlinks, so you can easily navigate between man pages"

Many terminals and shells support these features already.

"Finally we add visualisations so you can view plots of lines of code, etc., without having to context-switch."

Huh? I read that as 'code folding' and clang compilation.

I think the main takeaway here is that most of his "ideas" can be easily achieved within the current ecosystem of available programs, most of which are stock on modern UNIX-like OS distributions. I do think he misfiled this article under "Ideas"; it's more akin to a polite rant.

edit: colours/color killed due to conflict with reality (and irrelevance anyway).

Weak typing and implicit coercion are not the same thing. They're not even close to the same thing. Haskell does (things equivalent to) implicit coercion when it adds a floating-point Number to an integral Number and nobody (sane) says Haskell is weakly-typed.