In CLIM, a graphical presentation is only a representation of an underlying type. Types will have default representation (e.g., basic text like you would get from printf), but you can also override this using with-output-as-presentation (see p. IV-1.30 of [1]).

So, when outputting a number, you could display it in the output stream as a circle of radius N. Then, any input which wanted a number as argument (using "(accept 'integer ..)") would let you type a number or click on that circle.

This could be extended to shell command parser for richer input choices (rmdir can only accept directories, cat won't). Existing utilities could support a "richly typed stream of objects" (graphical ls) or a wrapper or output processor could add it. The latter has the advantage that not all commands would need to be aware, and it could be multi-functional (could work on "ls|grep", "find", "tar tf" output--but you might need to specify type hints).

I think it would be handy to have all my recent files, directories, outputs handy in a list on the side (with keyboard shortcuts too; I'm not a clicker..).

So in no way should your command history have to be compromised just because you have alternative input methods available.

[1] A Guided Tour of the Common Lisp Interface Manager, http://3e8.org/pub/scheme/doc/lisp-pointers/v4i1/p17-rao.pdf

well, not at that minute level, but every application worth its name has an undo log - and that's a pretty close functional equivalent, IMO.

And: applications that have Macro recorder features (Office and many text editors) allow you to actually record your actions - clicks or otherwise - into code that can be rerun.

The problem there is that every application needs to implement a macro recorder, and every application needs to implement history and undo. With small programs that all handle text the shell takes care of history and automation, while the other programs can focus on solving a new problem.

Why have macros and history reimplemented badly by every application when one application could do it well?

True, such a feature should really be system-wide - something like OSX's Automator, maybe.

That doesnt take away from the point, however, that GUI actions can be stored in history, composed, etc.

But right now, they aren't. :)

Hah, but here we come back to my question: which was specifically not about what we do have "right now", but why those things that we do have right now are worse than the things "we" had before??

It's perfectly possible for a GUI to have a command history, if the GUI is just a front end to a CLI. Then you can click around when you want to explore, and can go to over to the CLI when you know what you want to do and want to establish a more streamlined workflow. Or even click around and do stuff, and then extract a script from that recent history of clicks and interactions.

Some R (programming language) GUI frontend does it in this way.

Not sure why, but I'm reminded of the old WordPerfect dual mode, with rendered text on top and raw mode on the bottom. It was a little annoying because sometimes that was the only way to get something done, but it was also fairly powerful.

It would be kind of cool to have gui interfaces (including the general desktop gui) have something like this dual mode.

Some CAD programs do this. You could execute a command with fully defined parameters to make something happen, or maybe you'd execute the command and enter the parameters by selecting things in the GUI when prompted. It is a very powerful way to work, but the learning curve is often steep.