Re: completion test suggestion

Re: completion test suggestion

[Sven Wischnowsky]

I wrote:

> 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.

After thinking more about this: for this example the test
`(( -rangebeg(s1,s2) ))' should already be enough. For other tests we
could just add some helpful functions, e.g. `prefix(s1,s2)' which
returns the length of the common prefix of both strings and so
on. Such functions may be helpful in writing shell functions that do
matching anyway and with a good set of such functions we could put all 
tests together in one `(( ... ))'.

Bye
 Sven


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

Re: completion test suggestion

[Sven Wischnowsky]

Bart Schaefer wrote:

> Sven Wischnowsky writes:
>  > In mathematical environments you can use expressions like
>  > `foo(x,y)'.
> 
> The problem that I have with this is that I don't know whether the value
> of the function is its exit status or its standard output.  To behave
> like a unix tool (say, `expr`) you'd want to capture its output and use
> that; but if it's a shell function it'd be much easier to capture its
> exit status (no fork/read required).  But then the truth/falsehood of
> zero/nonzero exit status is reversed in math context, which is really
> confusing.

I thought about using the return value or the value of a parameter,
the function sets (`REPLY'?). But we needn't allow shell functions
here (or add this later). If we have only builtin (in the base or in
modules) functions this isn't a problem.

> The other difficulty is that you have to call the function twice (or
> call two different functions) to produce the start and end values of a
> range, if what you want is some slice of $words.

Compared to a parameter expansion in a subscript this would still be
faster, I think (if that is the problem you mean).


Bye
 Sven


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

Re: completion test suggestion

[Bart Schaefer]

Sven Wischnowsky writes:
 > In mathematical environments you can use expressions like
 > `foo(x,y)'.

The problem that I have with this is that I don't know whether the value
of the function is its exit status or its standard output.  To behave
like a unix tool (say, `expr`) you'd want to capture its output and use
that; but if it's a shell function it'd be much easier to capture its
exit status (no fork/read required).  But then the truth/falsehood of
zero/nonzero exit status is reversed in math context, which is really
confusing.

The other difficulty is that you have to call the function twice (or
call two different functions) to produce the start and end values of a
range, if what you want is some slice of $words.

I guess I could live with this if we can't come up with anything better,
but I'd still like to try to come up with something better.

Re: completion test suggestion

[Sven Wischnowsky]

I wrote:

>     [[ -after str ]] ->     if (( rangebeg(str) < CURRENT )); then
>                               shift 'string(str)' words 
> 
>                                 (or: words=(${(@)words[string(str),-1]}"))

Plus the modification of `CURRENT' of course:

                                (( CURRENT -= string(str)-1 ))

Sorry.

Bye
 Sven


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

completion test suggestion

[Sven Wischnowsky]

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