Let's finish this new completion stuff

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Before I get tired of asking the same questions again and again, I'll
write down all the things I'm thinking about and which I'd like to
discuss before we start implementing them.


*Please* take the time to send comments, suggestions, answers,
questions or whatever.


The special parameters:

- Using the positional parameters as we do now has some drawbacks. We
  could make the completion widget store them in another array but
  then the modifying tests (see below) would still change `argv'
  unless we make the test get the name of the array to work upon as an 
  argument. But then we could equally well let users use `read' to get 
  the words (which I wouldn't like but that may be only my problem).
  Of course we could also make the completion code store the words in
  an array and give them as positional parameters. The we would have
  the problem mentioned by Bart that the value of CURRENT may be off
  by one for those who use `ksharrays', unless we use the setting of
  that option when setting CURRENT in the completion code.
- I would like to remove the parameter `COMMAND' since this has
  already become yet another way to describe the context (`COMMAND' is 
  a bit of a misnomer currently). When using an array to report the
  words on the line we could store it in this array as the first word
  which should make non-automatic modification of this array
  easier. With that we could get rid of the `command' or `argument'
  CONTEXT, replacing both of them with one name.
- We could also put the `COMMAND' into the `CONTEXT' parameter which I 
  would like to replace with a associative array with keys:
  - `command'   if this is used as the replacement for `COMMAND'.
  - `redirect'  for the string of the redirection operator
  - `parameter' for the `value' and `subscript' contexts where it will 
                contain the name of the parameter
  - `type'      as the replacement for the old `CONTEXT'
  - `quote'     if we want to do this, this could be set to `single',
                `double', or the empty string giving information about 
		the quotes the completion code thinks we are in
  We may find other interesting things here and with an associative
  array it would be easy to add new types of context information.
- The example code currently uses the return value of the shell
  functions or a parameter (in the new version I just sent) to decide
  whether more completion definitions should be used. This can not be
  combined with `compcall' which currently gives no information about
  things like that. I'm not too sure about this, but maybe we would
  want to add a special parameter that will be used by `compcall' and
  that can also (of course) be used in the shell code. (Someone else
  should decide this since I don't care that much about `compctl' any
  more.)


The testing problem:

Some of the condition codes we currently have could easily be replaced
by shell code so we should probably remove them. The question was/is
with what we would replace them. There seems to be support for doing
this with a builtin and indeed some of the examples have shown that we 
sometimes only need the modification, not the result of the test. So
that is already almost decided, but I'd like to put it into a builtin
that does not only the testing. I already spoke about my wish to add a 
builtin that gives control over some of the surrounding completion
code and I'd like to put it there. That builtin would have several
options (again):

- Options to control the special parameters. For the modifications we
  could either add one option per modification (e.g. using the
  characters known from `compctl -x': `-s <str>' and the like), or use 
  (nearly) the syntax Bart sometimes used (although I don't know if
  this was suggested syntax): `-m ignored-prefix <str>'.
  With these/this option(s) the builtin would set it's return value in 
  a way that it can be used for testing, but that would only be a
  `side effect'.
  Here we could also add a built-in replacement for the `compsave' and 
  `compreset' aliases from the example code. Let's give it two options 
  to save and restore the state of all the special parameters. It
  would be the user's responsibility to make those calls symmetrical.
- Options to get information from the calling completion code,
  e.g. things like `is there already a valid list', `will menu-
  completion be used' (which would also test for automenu) and the
  like.
- Options to say what should be done with the matches genereated,
  e.g.: `list them', `don't list them', `use menu-completion', `insert 
  it into the line', etc.

I really think we should have a way to specify things like the last
ones, giving full control to the user. Later we may use this builtin
to give access to the matches already generated, allowing users to
look at them, change them, or delete them. Also we could then clean up 
the `-U' and `-m' options to `compadd' (the way Peter already suggested
it): making `compadd' do matching unless the `-U' option is used and
remove the `-m' option. What keeps me from doing this already is that
`-U' switches on menu-completion which is not what one wants if the
function using `compadd' did the matching.


Miscellaneous:

- As Bart already said, the name `complist' is a misnomer (I was
  thinking about `it adds a list of matches...'). Any suggestion for a 
  better name from someone who knows more English synonyms or has more 
  ideas than I would be welcome (we could use `compctl' for it, making 
  it behave differently when called from a completion widget...).
- Since `compctl' is already used I'd also like to hear suggestions
  for the control-builtin I proposed.
- I already spoke about the `problem' with completion after `~', `=',
  and `$' when `complist' is used. Currently the code automatically
  uses the builtin way to complete in such places. I'd like to change
  this by making `complist' behave as if it didn't know better and
  adding contexts reported to the user via the `context' parameter for 
  these circumstances. The question is: should I add contexts for `~'
  and `=' - almost doesn't look like it's worth it.
- Bart suggested making the leading underscore special in the
  `functions' builtin and `compctl -K ...'. I like this, but I'd like
  to hear what others think about it before...


Ok. I'm curious if I get answers this time.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx