Re: PATCH: compadd (+ questions)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Feb 12,  9:42am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: compadd (+ questions)
}
} > The point being that, although being able to add conditions in modules is
} > a cool thing, perhaps we should drop the ones that are easily replicated
} > using simple tests on the variables, and then look again at the rest to
} > see if there's a better way to express them.
} 
} Agreed, although I'm not sure if I'll produce a patch for this any
} time soon.

If you're about to do new doc, though, you shouldn't spend time documenting
something that's going to go away ...

} > 	tryprefix () {
} > 	    complocal	# Equivalent of "local CURRENT NMATCHES ...",
} > 	    		# if "local" worked on special parameters
} > 	    comptest ignored-prefix $1 && { shift ; "$@" }
} > 	}
} > 	tryprefix - complist -k "($signals[1,-3])"
} 
} Ah, now I finally understand why you wanting restting in function
} scopes. One problem I have with this is that we can come up with a few 
} functions for the tests, but the things to do if the test succeeds can 
} often not easily be put in a command line.

That's just a matter of more shell functions:

    listsignals() { complist -k "($signals[1,-3])" }
    tryprefix - listsignals

but you're right that a real syntactic construct would be much cleaner.

Maybe we can figure out a way to make "local" work inside { ... } ?  I've
seen some postings on zsh-users that lead me to believe some people think
it does already.

} Also we often need combinations of tests, for and'ed tests this would
} lead to things like `tryrange -exec \; tryprefix - ...', but for or'ed 
} tests.

You wouldn't do it that way.  You'd write a special function for each
particular combination of tests you wanted, and then just call them in
the appropriate spots.  Yes, this is crude, but it's easy to explain and
use, in terms of existing zsh scripting concepts.

} Also, will the non-parameter-modifying tests have equivalent
} functions or will this lead to combinations of such function calls and 
} `[[...]]' conditions? This can get very hard to read, I think.

My thought was that only the tests with side-effects get a builtin.  I
don't think the mixture will occur often enough to get that confusing.
If you don't need to "local"-ize the side-effects, which in at least
some cases you won't, you can just write stuff like

    if test $NMATCHES -eq 0; then
	...
    elif comptest ignored-prefix - ; then
	...
    elif ...
	...
    fi

I.e., use "test" if it's really important to avoid mixing [[ ... ]] with
plain ol' command syntax.

} About using argv for the stuff from the command line. I'm not too
} happy with this anyway. If the new style completion is slower than the 
} old one, this may partly be caused by several calls to sub-functions where 
} we have to use "$@" to propagate the positional parameters.

So don't propagate it via positional parameters after the first level.
Having them in the positionals is a convenience for when the top-level
completion function doesn't need to be as complex as __main_complete,
e.g., when writing special key completions.

For Functions/Completion/*, something like this:

    alias compsub 'words=( "$@" ) __normal || return 1'

or just have __main_complete assign to a local $words and then use it in
place of $argv in all of the sub-functions.

} > So why don't we actually DO that?  That is, make a "recursive" call to
} > the whole completion system?  Add -iprefix, -position, -string, -class
} > options to "compcall" (or some similar new command) and have THAT adjust
} > the variables, re-invoke the appropriate main completion function, and
} > then restore everything
} 
} Only seldom do we want to do normal completion after adjusting the
} word/words to use. In most cases we want to do some very specialised
} calls to complist/compadd or whatever and we want only those
} matches.

OK, then, give compcall another parameter that's the name of a different
top-level completion function to use.  That'd also solve the positional
parameter propagation problem we just talked about.

Note that I'm talking here about adding functionality to the compcall
builtin, not to some new piece in Functions/Completion/.

More later ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com