completion test suggestion

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

I was thinking about Bart's suggestion yesterday, as a reminder:

  ${comptest[ignored(-)]}

Where the `ignored(-)' is a special kind of pattern. And this
`special' is what I didn't really like about it. But then finally it
reminded me of something I had in one of my private versions some
years ago: functions in mathematical environments. I had used a C-like 
syntax (of course). So why not use that? It would go like this:

In mathematical environments you can use expressions like
`foo(x,y)'. This will invoke the function `foo' and give it the
arguments `x' and `y'. The function can be a shell function or one
defined by a module. In modules they can cause the module to be
autoloaded. This would also be one step further to implementing
anything ksh can and once we have support for floating point
arithmetic, we could have a module `math' which gives access to the
functions from the math library and things like that (considering the
floating point stuff we probably should use the parameter `REPLY' in
shell functions to report the result instead of using `return ...').

In the completion code we would have (only for the complicated tests)
the non-modifying functions:

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

  ...the same for `-class'

    [[ -after str ]] ->     if (( rangebeg(str) < CURRENT )); then
                              shift 'string(str)' words 

                                (or: words=(${(@)words[string(str),-1]}"))

  ...always doing matching (no `-mafter')

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

In real life there would be better names for these functions, all
beginning with `comp' (any suggestions?).

To make this more friendly to the eye, we could also keep the
condition codes and make them non-modifying:

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

and so on.

Then we would only have to tell the users that mathematical
expressions now support functions which shouldn't be too
surprising. Otherwise there would be no special casing, no weird
specialised pattern syntax, almost no magic.

Oh well, if noone stops me soon, I may get really exited about this.


Bye
 Sven


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