zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Cc: pws@ifh.de
Subject: Re: 6-pws-2
Date: Tue, 31 Aug 1999 21:05:09 +0000	[thread overview]
Message-ID: <990831210509.ZM17261@candle.brasslantern.com> (raw)
In-Reply-To: <199908310815.KAA27365@beta.informatik.hu-berlin.de>

On Aug 31, 10:15am, Sven Wischnowsky wrote:
> Subject: Re: 6-pws-2
> 
> Peter Stephenson wrote:
> > - Personally, I prefer one single completion function for a suite of
> >   related commands like cvs or pbm, since the accumulated clutter (and
> >   added time to process completion files the first time) is large.  If it
> >   stays the way it is I will change the default for function installation
> >   to keep the subdirectories.
> 
> I agree that the increase in processing time is very ugly but I don't
> have a problem with the many functions. However, you won't find it
> hard to convince to support any attempt to clean this up. The
> increasing use of `_arguments' already made me wish to find a better
> way to give descriptions to it then by writing lots of functions that
> just call `_arguments'. I don't have any ideas about this yet, though.

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.

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.

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.

The question then would be, what does belong in the main dist ... Core,
Base, Builtins, and Commands, perhaps?  A few things from User?


  reply	other threads:[~1999-08-31 21:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-31  8:15 6-pws-2 Sven Wischnowsky
1999-08-31 21:05 ` Bart Schaefer [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-09-01  8:46 6-pws-2 Sven Wischnowsky
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-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=990831210509.ZM17261@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=pws@ifh.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).