Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: 6-pws-2
- X-seq: zsh-workers 7593
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: 6-pws-2
- Date: Wed, 1 Sep 1999 10:46:59 +0200 (MET DST)
- In-reply-to: "Bart Schaefer"'s message of Tue, 31 Aug 1999 21:05:09 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> Here's a radical suggestion: Let's convert _arguments back into C code,
> as a module. It could work rather like getopts (which it resembles in
> syntax already), it would improve performance, and it would permit us to
> use arbitrarily complex caching schemes without worrying about nested
> associative array syntax at the interpreter level.
>
> We might also consider looking at any of the functions in Core and Base
> that are very heavily used, and turn those into C modules as well. If
> the interfaces were properly documented, anyone who wanted to could still
> override them with a shell function.
This sounds like a idea I can easily start to like ;-) I think I would
prefer to put it all into one module, though. And we don't necessarily
have to work only on the shell function level. Maybe we can find
constructs that are used (or useful) in several functions and add
builtins for those (or all the other things modules can do now or in
the future).
We could also hack something to help `compinit' do its job.
> After all, part of the reason for breaking completion out into this kind
> of function interface was to identify useful primitives. As quickly as
> nearly everything has been converted to using _arguments, it would seem
> that we've identified at least one.
Right.
> Here's yet another radical suggestion: Let's package the bulk of the
> completion system separately from the main zsh distribution, and maybe
> recruit a volunteer (Sven? Tanaka?) to keep track of the completion
> shell function patches so that Peter can concentrate on the shell proper.
> Peter can still handle the actual releases, but he won't for example have
> to hold off making a base release for serious problems like the killjb()
> bug just because the rest of us are busily creating completers for every
> program on the planet.
Since I like working with completion shell functions very much, I
would even volunteer for that. But of course, I would need support
from people know those commands which I know nothing or only very
little of.
This could also be one more step towards something I like thinking
about: some sort of very light-weight package system: completion would
be one package with some sub-packages and we would change/replace
compinit/dump and friends with a somewhat more generalised package
control system (this sounds big, but currently I'm only thinking about
one function plus package-supplied init/dump/install code).
> The question then would be, what does belong in the main dist ... Core,
> Base, Builtins, and Commands, perhaps? A few things from User?
I think it'll be hard to decide which ones from User if we don't use
them all (current state, without things like `cvs' and `pbm'). Some of
them probably simplified to `standard' versions (e.g. `_find') and
then put special version in the package (or whatever we want to call
it).
Bye
Sven
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author