zsh-workers
 help / color / mirror / code / Atom feed
* Using the new completion system 'naked'
@ 2002-05-17 17:59 DervishD
  2002-05-17 18:36 ` Bart Schaefer
  0 siblings, 1 reply; 3+ messages in thread
From: DervishD @ 2002-05-17 17:59 UTC (permalink / raw)
  To: Zsh

    Hello all :))

    I was wondering, while reading documentation about the new
completion system, two questions:

    - Will the old 'compctl' completion system disabled in the
future? And if the answer is 'yes', when?

    - 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, I know, those are strange questions, but I'm quite curious
about the inner works of the new completion system.

    Moreover, if the answer is not very large: what advantages gives
the new completion mechanism over the old one?

    Thanks a lot :)))
    Raúl


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Using the new completion system 'naked'
  2002-05-17 17:59 Using the new completion system 'naked' DervishD
@ 2002-05-17 18:36 ` Bart Schaefer
  2002-05-17 19:41   ` DervishD
  0 siblings, 1 reply; 3+ messages in thread
From: Bart Schaefer @ 2002-05-17 18:36 UTC (permalink / raw)
  To: DervishD; +Cc: Zsh

On Fri, 17 May 2002, DervishD wrote:

>     - 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."

>     - 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.

>     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."

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,
with a way to customize them without rewriting them (zstyles), plus a
better-organized system for adding others as we go along.

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 than that
of `compctl -x', and correspondingly that more of the processing can be
described by shell functions which are presumably more readable and more
easily debugged than are the cryptic strings used by `compctl'.

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Using the new completion system 'naked'
  2002-05-17 18:36 ` Bart Schaefer
@ 2002-05-17 19:41   ` DervishD
  0 siblings, 0 replies; 3+ messages in thread
From: DervishD @ 2002-05-17 19:41 UTC (permalink / raw)
  To: schaefer, raul; +Cc: zsh-workers

    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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-05-17 19:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-05-17 17:59 Using the new completion system 'naked' DervishD
2002-05-17 18:36 ` Bart Schaefer
2002-05-17 19:41   ` DervishD

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).