From: DervishD <raul@pleyades.net>
To: schaefer@brasslantern.com, raul@pleyades.net
Cc: zsh-workers@sunsite.dk
Subject: Re: Using the new completion system 'naked'
Date: Fri, 17 May 2002 21:41:44 +0200 [thread overview]
Message-ID: <3CE55CF8.mail1N6113ITR@viadomus.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0205171123260.28884-100000@ns1.sodaware.com>
Hi Bart, and thanks a lot for answering :)
>> - Will the old 'compctl' completion system disabled in the
>> future? And if the answer is 'yes', when?
>The answers are "maybe, but probably not" and "nobody knows."
Well, just as I supposed ;)
>> - Can I use the new completion system without compinstall'ing it
>> and without compinit'ing it, just by suitably calling compadd,
>> compset and compcall (no compdef...)?
>Yes, of course you can. The `compinit' system is only one of many that
>could be built on top of the compadd etc. builtins. It just happens to
>be the best one we've come up with so far.
The compinit sistem is very good, but I prefer doing it myself,
and BTW I don't really need such a powerful and complicated system.
I've tried to read '_arguments', but... well, you know ;)
>> Moreover, if the answer is not very large: what advantages gives
>> the new completion mechanism over the old one?
>Depends on what you mean by "the new completion mechanism."
Both 'compinit' system and the new builtins, as your answer
suggest. Thanks a lot for all the explanations :)))
>If you mean "the `compinit' system" then the answer is very large but
>mostly boils down to having more completions available out of the box,
For me this is not an advantage, and that's the reason of my
question. But I must admit that for new users this is fantastic. All
the zsh contributors have done a very well job.
>If you mean the compadd/compset/etc. builtins only, plus `zle -C', then
>the advantage is meant to be that the syntax is less baroque
OK, I was supposing. The syntax of compctl is not easy and
sometimes difficult to read, but I find it clearer, shorter and more
concise than most of the functions in the 'compinit' system. Just an
opinion ¿ok?, I'm not telling that the functions are badly written.
>more easily debugged
This is true. Debugging of compctl can be very hard...
>One might observe that `_arguments' has become nearly as cryptic as
>`compctl', but on the other hand it's also doing a lot more work.
I tread '_arguments' as some kind of gibberish ;))) I've read it
a couple of times (not deeply...) and I don't feel it readable...
Well, I'm now pretty informed and more confident to make little
completions for compadd 'naked' just for the sake of doing it :)
Thanks a lot, you're great, Bart :)
Raúl
prev parent reply other threads:[~2002-05-17 19:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-17 17:59 DervishD
2002-05-17 18:36 ` Bart Schaefer
2002-05-17 19:41 ` DervishD [this message]
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=3CE55CF8.mail1N6113ITR@viadomus.com \
--to=raul@pleyades.net \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@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).