zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: 6-pws-2
Date: Wed, 1 Sep 1999 10:46:59 +0200 (MET DST)	[thread overview]
Message-ID: <199909010846.KAA32020@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Tue, 31 Aug 1999 21:05:09 +0000


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@informatik.hu-berlin.de


             reply	other threads:[~1999-09-01  8:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-01  8:46 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-08-31 12:38 6-pws-2 Sven Wischnowsky
1999-08-31 16:19 ` 6-pws-2 Tanaka Akira
1999-08-31  8:22 6-pws-2 Sven Wischnowsky
1999-08-31 11:28 ` 6-pws-2 Andrej Borsenkow
1999-08-31 17:10 ` 6-pws-2 Bart Schaefer
1999-09-01  8:24 ` 6-pws-2 Peter Stephenson
1999-08-31  8:15 6-pws-2 Sven Wischnowsky
1999-08-31 21:05 ` 6-pws-2 Bart Schaefer
1999-08-30 16:00 6-pws-2 Peter Stephenson
1999-08-30 21:03 ` 6-pws-2 Bart Schaefer
1999-09-01  8:09   ` 6-pws-2 Peter Stephenson
1999-08-31  3:37 ` 6-pws-2 Tanaka Akira
1999-08-31  9:27 ` 6-pws-2 Ollivier Robert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199909010846.KAA32020@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).