I'd just like to add that, while I arrived in a similar place to
Nicolas, I got there by quite a different route.
Earlier this week, I read The Unix Haters Handbook, which catalogues
all (well, many) of the horrendous design decisions that were made in
designing UNIX. The concept of the pipe got an entire chapter, and
the shell expansion of wildcards was frequently mentioned. This got
me to thinking about how a command-line should be designed.
I am sure that most of us on this list use a command-line on a
regular basis and know how powerful it is - not more powerful than a
GUI, or even more flexible necessarily, but powerful in a different
and complementary way.
One thing that has always irritated me is tab completion.
Specifically, how stupid tab completion is. For example, I type
`man' and then the only things I can tab-complete as arguments are
files in the current directory. Does this make sense? No. Very
well, how do we improve it?
The first step is that any command must publish its parameters in
some way. The ideal way would be for a command to be responsible for
handling the autocompletion in the same way that a combo box is in OS
X 10.3 and later.
The second thing that I began to think about was pipes. How should
they be handled? The `everything is an untyped stream of bytes'
metaphor is one that has always irritated me about UNIX, but the
Handbook really explained it well. Put simply, the problem is twofold:
1) There is no out-of-band data.
2) Communication is uni-directional.
What is needed is a mechanism for publishing input types accepted and
output types generated. Microsoft's DirectShow manages to handle
this well, and so it is a solvable problem.
In parallel, I thought about how this kind of functionality should be
exposed to the user through Étoilé components, and it seemed to me
that there was a simple solution:
Components already expose methods through StepTalk. What is needed
is a natural language wrapper around certain messages. This would
take the form of a fixed-syntax sentence with gaps left which could
be filled by certain typed information. The type of each gap could
be specified (e.g. person, file, time, string, array of people), and
the UI could then provide suggested completions for data of this type.
