Re: Let's finish this new completion stuff

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

I'm trying to reply simultaneously to Peter and Bart here...

Bart:
> Preliminary remark:  I think it's premature to be talking about "finishing"
> this stuff.  There are, what, three? people actually trying this out right
> now?  And one of them is the implementor of 90% of the underlying code.
> This is not the way to do a usability study.  I imagine we're going to be
> tweaking things for a long while.

Yes, I know that only too well. It was an attempt to draw more
attention to the mail... (sorry).

> } - 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'
> 
> Let me see if I understand this.  Referring to the tests that modify the
> word list as a side-effect:
> 
> As of the current date, those tests (a) expect to find the previous word
> list in the positionals, and (b) always stuff the new word list into the
> positional parameters of whatever function calls them.  So if you forget
> to pass the previous word list to a sub-function as its arguments, none
> of the tests work as expected.
> 
> Have I got that right?

Yep.

> If we don't use the positionals, we should use another special variable
> with a hardwired name, as PWS suggested.

That was what I meant, fine.

> What do you do in cases where COMMAND presently doesn't contain a real
> command name?

The `context'-name would be in the `CONTEXT'-parameter (or the one we
use to replace `CONTEXT'), the words from the line would still be in
the `words' array (e.g the words when completing inside an array value 
or inside a condition).

> } - We could also put the `COMMAND' into the `CONTEXT' parameter which I 
> }   would like to replace with a associative array with keys:
> 
> So whichever of these was uninteresting would simply not be set?

Yes (or empty).

> Anyway, let's call this hypothetical associative array `compstate' for
> purposes of discussion.
> 
> }   - `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'
> 
> I like `context' better.  `Type' means too many different things.

I was thinking about calling the array `context' and didn't like
`$context[context]'. If the parameter has another name, I'd prefer
using `context' as the key, too.

Peter now:
> This sounds OK, but if $COMMAND is really just going to be $words[1] or
> whatever it might be a bit confusing to put it here too --- for example, if
> you are completing after `nice' so that $words gets narrowed to whatever's
> after, does $context[command] refer to `nice' or to the next word, and when
> you change the context (shift words; (( CURRENT-- )) ) is the user or the
> shell responsible for changing it?  I think we should just stick to using
> $words or whatever name anyone else suggests, if that's agreed upon.

I meant to either store it in `words' exclusive-or in
`context'. The narrowing would be done by the shell when using the
modifying whatevers but could, of course be done in shell code (and
with everything in the `words' array this would be much easier).

Bart again:
> Why not put everything that's not another array in here?
> 
> 	CURRENT		-->	compstate[current]
> 	PREFIX		-->	compstate[prefix]
> 	IPREFIX		-->	compstate[ignored]
> 	SUFFIX		-->	compstate[suffix]
> 	NMATCHES	-->	compstate[nmatches]
> 	MATCHER		-->	compstate[matcher]

Actually, I thought about this, too. But `$PREFIX' looks so
nice. Still, I wouldn't mind stuffing everything into one associative
array.

Peter:
> > - 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.)
> 
> I'd have thought for anyone still using compctl it would be good enough
> just to be able to test $NMATCHES.  If anybody wants anything more
> sophisticated, they're going to be going over to new completion anyway.

*Good* (That's what I wanted to hear ;-)

Bart:
> } 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.
> 
> I have a radical suggestion:  Replace them with magic elements of the
> compstate array.  A special associative predefined by zsh doesn't have
> to be implemented by a simple hash table; it can do its own special
> interpretation of the subscripts.
> 
> Then we can invent a whole lot of new syntax for the completion stuff,
> and hide it where the lexer already skipparens() it.

I like `magic' syntax, but I'm not sure if the users would like it...

> [ examples for implementing tests in shell code ]
> 
> These are so messy I'm not going to try work them out on the fly here:
> 
> [[ -string str ]]
> ...
> [[ -mbetween pat1 pat2 ]]

I showed shell code for them in message 5386, possible, but...

> An alternate idea is to require the (r) or (R) subscript flags to make
> the magic syntax active, so you get something like:
> 
>     $compstate[(r)position(x)]	 if compstate[current] == x, expands
>     				 to $words[x], else expands to nothing
> 
>     $compstate[(R)position(x,y)] if compstate[current] is between x
> 				 and y, expands to $words[x,y]

Hm, I like this, but I'll need some more comments on it before
trying to implement something like this.

> I suggest making the existing list available in a parameter that can
> be tested and modified directly; the sets.afn of that array can do the
> equivalent of `compadd`.  For booleans like "are we menu-completing,"
> see the AA idea above.

Making the list of completions generated so far available isn't that
easy without disallowing adding further completions. Also, we can't
easily deliver all the information stored with an array. But now that
we are speaking about sepcial subscript-syntax anyway, how about:

  $matches[num][prefix]  gives the `compadd -p'-prefix of the num'th
                         match
  $matches[num][string]  the string to list

And so on. I've no idea how difficult to implement this would be,
though.

> } - 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.
> 
> Don't those options belong on complist/compadd?  Or is it not possible
> to have some of the matches listed and others not?  (That is, is it a
> requirement that there be a single global switch for this stuff?)

With `compadd' one can add matches that are not to be shown. But what
I meant is the post-processing and that can not be set on a per-match
basis (we can't have one half of the matches menu-completed and the
other half with normal completion). I hadn't thought about using the
associative array for this, though (as Peter suggested, too). But,
yes, you are right, if we make this a more complete
`context-information' thing, this kind of information could (or
should) be stored there (and taken from there after the completion
widgets finish).

> By the way, again, one thing I haven't figured out how to do with the
> new completion stuff is the equivalent of `compctl -X`.  How does one
> add an explanation string, and when does it get shown?

You just use `complist -X ...'. Explanation strings are stored with
groups of matches. So a `complist -X ...' stores a string in the
sorted group named `default'. To store strings in other groups one
would use `complist -J ... -X ...' (or `-V').

Peter:
> In other words, internal control of what the widget is really doing: `I'm
> fed up with being an expand-or-complete, I want to be a list-choices'.
> Maybe this needs to integrate somehow with `zle ...' calls, but I can't
> offhand think how.

Hm, hadn't thought about `zle ...' and have no ideas now.

> I presume it's easy enough to tell whether you're completing after a ~
> anyway -- just look to see if there's a slash yet.  The advantage of
> something like a context would be you can finally solve the problem compctl
> -T was invented to solve in a modular way, i.e. making your own list of
> usernames.  With a context you can just plug in your own comps[-tilde-] by
> the autoload-scanning mechanism.  Thinks: this doesn't have to be a context
> generated by the C code, there's nothing to stop _normal looking up
> $comps[-tilde-] by itself if it thinks that's a good idea, [and maybe
> completing users if there isn't one (it can even check $COMPSKIP) --- but
> perhaps the best idea would be to provide a _tilde handler for -tilde-
> which the user then modifies directly].

Yes, that's what I was thniking about. Let the C-code do the test for
`$...' (which isn't that easy with all the flag-parsing and so on) and 
let the widget do the `[[ -iprefix '~' ]] ...' or whatever.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx