separate the command language and interactive

[David Gudeman]

In article  <-#8Gd-e*1 at cs.psu.edu> Felix Lee writes without
understanding anything that he is replying to:

]>  <command-line> ::= <command> <arg>* | "set" <var> = <arg>
]>  <arg> ::= "-"<char>* | "$"<var> | <file>
]>  path-complete <command> with "echo $path"
]>  path-complete <file> with "pwd"
]>  list-complete <var> with "variable-completion %s"
]
]Let's see.  The syntax is naive: it doesn't do quoting of any sort, so
]you can't do file completion on files with special characters in it.

I can make the syntax as complex as needed and do file completion with
any characters.

]How about completing filenames with variables embedded: "$HOME/$a/a".

This is a non-problem.  The ish gets the value of the environment
variable and completes however the ish-writer thought it should be
done.

]How about history completion: expand things like "!$" and "!vi".

History is entirely handled in the ish.  If the ish writer thinks
there should be history completion there can be.

]How about glob completion: expand things like "*" and "f*".

If the ish writer wants to expand wildcards, the ish can do so.

]A more serious problem: the shell isn't the only thing that
]wants/needs completion.  gdb, for example, wants to do completion.

That was one of the considerations that lead to my suggestion in the
first place.  Write a command line description for gdb just like for
the clang.

]Teaching the front-end about all this gets ugly.

All of this is part of the front end, there is no "teaching" about it.

]The simplest way to handle completion is to have a communication
]channel between the front-end and the current interactive process.

It might make life a little easier for the ish writer, but it makes
life harder for the clang writer.  Since completion is an ish feature,
the clang writer should not have to worry about it.

](Which immediately has two problems in Unix: What's the "current
]interactive process"?  How do I talk to it?  (So how do we fix Unix?))

My supposedly more complex scheme doesn't have either problem.
--
					David Gudeman
gudeman at cs.arizona.edu
noao!arizona!gudeman