From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-5681-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 1625 invoked from network); 8 Mar 1999 12:53:25 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 8 Mar 1999 12:53:25 -0000
Received: (qmail 11390 invoked by alias); 8 Mar 1999 12:52:58 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 5681
Received: (qmail 11383 invoked from network); 8 Mar 1999 12:52:56 -0000
Date: Mon, 8 Mar 1999 13:52:01 +0100 (MET)
Message-Id: <199903081252.NAA11834@beta.informatik.hu-berlin.de>
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
In-reply-to: Peter Stephenson's message of Sun, 07 Mar 1999 16:30:26 +0100
Subject: Completion TODO (was: pws-11)


Peter Stephenson wrote:

> Status report on completion: the parts changed this week (complist is now
> called compgen, many of the variables have been absorbed into the
> associative array $compstate) are probably near their final form --- at
> least, until someone other than the four of us tries it out and finds they
> don't like it.  However, Sven still plans to add some other bits,
> e.g. controlling the re-display of an existing completion list.

I was planning to do this anyway and having to leave early today so
that I won't be able to do some real work anyway...


Here is the list of things for the new completion stuff we might want
to think about, add, or modify, collected in one place. There may be
others things, but these are the ones, I could think of.


Testing (and saving/restoring of `PREFIX'...):

The current state: condition codes, some of them modifying. Saving and 
restoring of the special parameters is done automatically on function
entry and exit (and nowhere else).
The problems are: modifying condition codes are considered a bad thing 
and saving/restoring has to be done explicitly.

Suggestions made:

- Bart's special associative array. Let's call it `comptest', then one 
  could do: `comptest[(r)string(-1,foo)]' to get the index of the last
  `foo' in `PREFIX'. Thus we would have:

    index=$comptest[(r)string(-1,foo)]
    if (( index )); then
      IPREFIX="$IPREFIX$PREFIX[1,index]"
      PREFIX="$PREFIX[index+1,-1]"

  and probably:

    subarr=("${(@)comptest[(r)range(-exec,\;)]}")
    if (( $#subarr )); then
      words=("$subarr[@]")

  The only problems I see with this are implementation issues (haven't 
  tested how difficult to implement this would be yet) and the fact
  that this looks a bit weird (that may be caused by not being used to 
  it, though).

- Andrej suggested keeping the condition codes and changing them to
  not modify `PREFIX' and friends directly. Instead they would set
  other special parameters (say, `INDEX', `FIRST', `LAST'). With this:

    if [[ -string -1 foo ]]; then
      IPREFIX="$IPREFIX$PREFIX[1,INDEX]"
      PREFIX="$PREFIX[INDEX+1,-1]"

  and:

    if [[ -between -exec \; ]]; then
      words=("${(@)words[FIRST,LAST]}")

  Obviously this has the advantage of being very short and readable
  (and could be made more readable by providing a function that does
  the modification and then calls the match-generating function(s) or
  builtins).
  The only thing I don't like about it (once I have been convinced
  that condition codes should be non-modifying), is that they again
  modify some global state -- it's only in different parameters.

- I suggested using functions in math environments or using only the
  already existing parameter expansion magic, e.g. (if combined with
  the condition codes we have, turned into non-modifying ones again):

    if [[ -string str ]]; then
      IPREFIX="${IPREFIX}${PREFIX[1,string(str)-1]}"
      PREFIX="${PREFIX[string(str),-1]}"

    if [[ -between s1 s2 ]]; then
      words=("${(@)words[rangebeg(s1,s2),rangeend(s1,s2)]}")

  or (with parameter-magic):

    if [[ -string num str ]]; then
      index=$PREFIX[(in:num:)str]
      IPREFIX="$IPREFIX$PREFIX[1,index]"
      PREFIX="$PREFIX[index+1,-1]"


    if [[ -between s1 s2 ]]; then
      i1=$words[(Ib:CURRENT:)s1]
      i2=$words[(ib:i1:)s2]
      words=("${(@)words[i1+1,i2-1]}")

  Since I think I'm the only one who likes them, I won't comment any
  further...

- Apart from the rest it was suggested (by Bart) to have functions
  that do the tests, modify the parameters and then call other
  functions to generate the matches. Of course, this could already be
  implemented. In most cases, however, functions that do all the tests 
  on the arguments or the current word themselves and then call the
  match-generating functions or builtins directly somehow feel more
  natural (and probably are more readable, although that depends on
  the way the testing functions would be implemented).
  With this we wouldn't need more support for saving/restoring the
  parameters. I'd like to point out, that this isn't needed very often 
  anyway (only if the parameters are used again after the test
  succeded) and that the only clean solution would be a syntactic
  construct that restores the state of the parameters -- and
  implementing that is out of the question, I think.
  So, I think we don't need to imlpement anything new for this in C.
  We could implement some testing functions if we feel the need (and
  with the `words' array we have now this would be easier than before) 
  and otherwise let the user do the modification by hand so that he
  knows that he has to restore them afterwards.


Widget-return value:

Andrej suggested using the return value of the widget for
`continuing' when called from `compctl -i'. I.e. if it returns
non-zero, no other `compctl's are tried (or the other way round). I'd
prefer to do this with another key to `compstate' and use the return
value of completion widgets the same way they are used for normal
widgets -- which is still to be defined (and implemented).


More `compstate':

There are some things I'd like to give access to using `compstate' (or 
probably another associative array), namely:

- Control for beeping. I'm not to sure about this one because I don't
  use beeps, so anyone who relies on it should comment if he likes to
  have control over it (and how).
- Access to pre-existing sets of matches, i.e. be able to find out:
  - if there is a valid set of matches
  - if we are in a menucompletion
  - which match is currently inserted in the line (I'd like to be able 
    to give information about the group this match is in and which of
    the matches is on the line, and which groups are in the set, and ...)
    together with this: a way to say: `keep the old set and insert
    match ... from it' -- maybe we find a way to combine this with
    `compstate[insert]'
    and this together with `accept the current match and continue with 
    match ... after it' -- for things like accept-and-menu-complete
  - if the set of matches is shown (`listed')


Access to matches:

Finally there may be interest in giving access to all the information
we have about the current set of matches (the old one or the one newly 
built). Since there is so many information, we can't easily do this
with a special parameter (it is not only one string per match). Maybe
a builtin would be better, modeled after the `stat'-module, so that
the builtin could put all the information for one match into an
associative array. With this builtin we probably could also add a way
to modify the existing matches (in a controlled way).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de