From: Sven Wischnowsky <wischnow@berkom.de>
To: zsh-users@sunsite.dk
Subject: Re: zsh's answer to the bash completion fm project
Date: Thu, 4 Apr 2002 12:07:04 +0200 [thread overview]
Message-ID: <15532.9672.383882.876427@wischnow.berkom.de> (raw)
In-Reply-To: <20020404085836.GB24184@io.com>
John Buttery wrote:
> ...
>
> So that changes my original question to: Can/should we have a file for
> compctl recipes, and then a directory containing the files for the stuff
> made with the new system?
About the compctl part: I'd only consider such a list of
compctl-commands to be a todo-list of things that should be
implemented for the new system. And that may actually be helpful.
I'm not sure that there will be many such cases, though, with the new
system being as comprehensive as it already is.
About the function-directory: the new system uses a hierarchy of
directories for classification and easier management. New functions
will and should be put into it (and hence will end up in the
distribution).
For both parts: one of the things to look out for is opinions and
suggestions for different ways completion behaves. We recently had
someone who user@host completions to be inserted in one go, not with
`us<TAB>ho<TAB>'. Collecting such things would be interesting so that
we get a list of things we can try to make possible in the new system.
> Oh, and to the people who wrote me privately, pointing out that
> compctl is strongly deprecated in favor of the new system, that it
> sucks, etc etc...yes, I know this, I wasn't suggesting we advocate using
> it. All I meant was that if a recipe exists for compctl and hasn't been
> ported to the new system yet, we should still include it unless using
> both systems at once is impossible and/or a huge resource hit.
I think they can still be combined, at least they should. The
overhead for compctl from a user's point of view is basically that
there is another module loaded (for systems without dynamic linking it
has to be linked into the zsh binary). From my point of view there is
quite a bit of legacy code in the completion code that's only needed
to support compctl. And I hate that, but don't see a way around it.
Bye
Sven
--
Sven Wischnowsky wischnow@berkom.de
next prev parent reply other threads:[~2002-04-04 10:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-03 11:05 John Buttery
2002-04-03 12:09 ` Sven Wischnowsky
2002-04-03 14:54 ` John Buttery
2002-04-03 12:24 ` Thomas Köhler
2002-04-03 14:58 ` John Buttery
2002-04-03 15:10 ` Sven Wischnowsky
2002-04-03 15:56 ` John Buttery
2002-04-03 22:05 ` Bruce Stephens
2002-04-04 8:58 ` John Buttery
2002-04-04 10:07 ` Sven Wischnowsky [this message]
2002-04-04 13:28 ` John Buttery
2002-04-03 15:19 ` Thomas Köhler
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=15532.9672.383882.876427@wischnow.berkom.de \
--to=wischnow@berkom.de \
--cc=zsh-users@sunsite.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).