zsh-workers
 help / color / mirror / code / Atom feed
* Completion collision, best way to fix
@ 2012-09-28  9:33 Baptiste Daroussin
  2012-09-28 14:59 ` Bart Schaefer
  0 siblings, 1 reply; 8+ messages in thread
From: Baptiste Daroussin @ 2012-09-28  9:33 UTC (permalink / raw)
  To: Zsh workers

Hi,

I am working on a completion function for the freebsd new package
manager, actually it is working:
https://github.com/pkgng/pkgng/blob/master/scripts/zsh/_pkg

I want to add the completion function to the main zsh git but I face
the problems:
The right place for it would be Completion/BSD/Command, but if I put
it there it will hide the Completion/Solaris/Command/_pkg5 has they
both define #compdef pkg

Is there a nice way to deal with this situation?

Merging both functions into one and pushed into unix, and condition
the completion base on the OSTYPE?

or is there some kind of #compdef_only_on_solaris pkg
#compdef_only_on_freebsd pkg thing available ?

regards,
Bapt


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

* Re: Completion collision, best way to fix
  2012-09-28  9:33 Completion collision, best way to fix Baptiste Daroussin
@ 2012-09-28 14:59 ` Bart Schaefer
  2012-09-29  1:12   ` Danek Duvall
  0 siblings, 1 reply; 8+ messages in thread
From: Bart Schaefer @ 2012-09-28 14:59 UTC (permalink / raw)
  To: Zsh workers

On Sep 28, 11:33am, Baptiste Daroussin wrote:
}
} I want to add the completion function to the main zsh git but I face
} the problems:
} The right place for it would be Completion/BSD/Command, but if I put
} it there it will hide the Completion/Solaris/Command/_pkg5 has they
} both define #compdef pkg
} 
} Is there a nice way to deal with this situation?

Theoretically, you ignore it and put the completion in BSD/Command/.
It's not the only such conflict.

The reason there are separate directories BSD/ and Solaris/ and so on
is to permit the person doing the install on one of those systems to
include or omit only the appropriate subset of completions -- or to
permit the user to omit the irrelevant ones from $fpath, if the
installer configured with --enable-function-subdirs (the default).

In practice I'm not sure any of the distribution package maintainers 
actually take the step of removing the "irrelevant" functions from the
tree; maybe some change the default fpath in /etc/zshrc or the like.


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

* Re: Completion collision, best way to fix
  2012-09-28 14:59 ` Bart Schaefer
@ 2012-09-29  1:12   ` Danek Duvall
  2012-09-29  1:39     ` Baptiste Daroussin
  2012-09-29  1:53     ` Phil Pennock
  0 siblings, 2 replies; 8+ messages in thread
From: Danek Duvall @ 2012-09-29  1:12 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh workers

On Fri, Sep 28, 2012 at 07:59:36AM -0700, Bart Schaefer wrote:

> In practice I'm not sure any of the distribution package maintainers 
> actually take the step of removing the "irrelevant" functions from the
> tree; maybe some change the default fpath in /etc/zshrc or the like.

Given that I'm the zsh integrator for Solaris ...

Is there a way for the build process to put the "native" OS-specific
directory ahead of the rest?  If not, would a patch to do that be
appreciated?  I could take the easy way out and simply drop the BSD _pkg
from the Solaris zsh package, but it'd be nice not to have to.

Thanks,
Danek


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

* Re: Completion collision, best way to fix
  2012-09-29  1:12   ` Danek Duvall
@ 2012-09-29  1:39     ` Baptiste Daroussin
  2012-09-29  1:56       ` Danek Duvall
  2012-09-29  3:40       ` Bart Schaefer
  2012-09-29  1:53     ` Phil Pennock
  1 sibling, 2 replies; 8+ messages in thread
From: Baptiste Daroussin @ 2012-09-29  1:39 UTC (permalink / raw)
  To: Danek Duvall, Bart Schaefer, Zsh workers

2012/9/29 Danek Duvall <duvall@comfychair.org>:
> On Fri, Sep 28, 2012 at 07:59:36AM -0700, Bart Schaefer wrote:
>
>> In practice I'm not sure any of the distribution package maintainers
>> actually take the step of removing the "irrelevant" functions from the
>> tree; maybe some change the default fpath in /etc/zshrc or the like.
>
> Given that I'm the zsh integrator for Solaris ...
>
> Is there a way for the build process to put the "native" OS-specific
> directory ahead of the rest?  If not, would a patch to do that be
> appreciated?  I could take the easy way out and simply drop the BSD _pkg
> from the Solaris zsh package, but it'd be nice not to have to.
>
> Thanks,
> Danek

What we could do is to provide a Unix/_pkg
Which will do the #compdef pkg and call _pkg5 on Solaris and _pkgng on FreeBSD?

if you agree on that I'll do the work and send it to you for review

While you are here will you accept FreeBSD specific completion for
_zfs ? :D like the jail/unjail subcommand

regards,
Bapt


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

* Re: Completion collision, best way to fix
  2012-09-29  1:12   ` Danek Duvall
  2012-09-29  1:39     ` Baptiste Daroussin
@ 2012-09-29  1:53     ` Phil Pennock
  1 sibling, 0 replies; 8+ messages in thread
From: Phil Pennock @ 2012-09-29  1:53 UTC (permalink / raw)
  To: Danek Duvall, Bart Schaefer, Zsh workers

On 2012-09-28 at 18:12 -0700, Danek Duvall wrote:
> On Fri, Sep 28, 2012 at 07:59:36AM -0700, Bart Schaefer wrote:
> > In practice I'm not sure any of the distribution package maintainers 
> > actually take the step of removing the "irrelevant" functions from the
> > tree; maybe some change the default fpath in /etc/zshrc or the like.
> 
> Given that I'm the zsh integrator for Solaris ...
> 
> Is there a way for the build process to put the "native" OS-specific
> directory ahead of the rest?  If not, would a patch to do that be
> appreciated?  I could take the easy way out and simply drop the BSD _pkg
> from the Solaris zsh package, but it'd be nice not to have to.

You can use --enable-additional-fpath to add entries to the default
fpath; the order used is "site", "additional", "install locations".
Since the list is scanned in order, uniqueness isn't required and you
can just replicate an entry that will appear later.

See the "INSTALL" file for details on the syntax of the option.

If runtime works, then just:
  typeset -U fpath
  fpath=(${fpath[(R)*/Solaris]} $fpath)

-Phil


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

* Re: Completion collision, best way to fix
  2012-09-29  1:39     ` Baptiste Daroussin
@ 2012-09-29  1:56       ` Danek Duvall
  2012-09-29  3:40       ` Bart Schaefer
  1 sibling, 0 replies; 8+ messages in thread
From: Danek Duvall @ 2012-09-29  1:56 UTC (permalink / raw)
  To: Baptiste Daroussin; +Cc: Bart Schaefer, Zsh workers

On Sat, Sep 29, 2012 at 03:39:24AM +0200, Baptiste Daroussin wrote:

> What we could do is to provide a Unix/_pkg
> Which will do the #compdef pkg and call _pkg5 on Solaris and _pkgng on FreeBSD?

Works for me -- it's certainly a far simpler solution -- though I hardly
have the final say on that.  Phil's solution would work for me, too.

> While you are here will you accept FreeBSD specific completion for
> _zfs ? :D like the jail/unjail subcommand

Sure.  As long as the CLIs don't diverge too strongly, and the OS checks
don't complicate the script too badly, that works just fine for me.  That's
why either Bart or Peter asked that it be put in Unix rather than Solaris
in the first place.

Danek


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

* Re: Completion collision, best way to fix
  2012-09-29  1:39     ` Baptiste Daroussin
  2012-09-29  1:56       ` Danek Duvall
@ 2012-09-29  3:40       ` Bart Schaefer
  2012-09-30 20:47         ` Oliver Kiddle
  1 sibling, 1 reply; 8+ messages in thread
From: Bart Schaefer @ 2012-09-29  3:40 UTC (permalink / raw)
  To: Zsh workers

On Sep 29,  3:39am, Baptiste Daroussin wrote:
}
} What we could do is to provide a Unix/_pkg
} Which will do the #compdef pkg and call _pkg5 on Solaris and _pkgng on
} FreeBSD?

If you're going to do that, the correct way is to use _pick_variant
(Completion/Base/Utility/_pick_variant) to decide which flavor of "pkg"
you have.  That way people can use zstyle to control the choice.

} While you are here will you accept FreeBSD specific completion for
} _zfs ? :D like the jail/unjail subcommand

Have to wait for PWS to chime in, but generally speaking you can just
send it to zsh-workers for review ... of all the reasons it might be
rejected, being FreeBSD-specific is pretty far down the list.


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

* Re: Completion collision, best way to fix
  2012-09-29  3:40       ` Bart Schaefer
@ 2012-09-30 20:47         ` Oliver Kiddle
  0 siblings, 0 replies; 8+ messages in thread
From: Oliver Kiddle @ 2012-09-30 20:47 UTC (permalink / raw)
  To: Zsh workers

Bart wrote:
> If you're going to do that, the correct way is to use _pick_variant
> (Completion/Base/Utility/_pick_variant) to decide which flavor of "pkg"
> you have.  That way people can use zstyle to control the choice.

_pick_variant distinquishes the program variants by running them,
usually with an option such as --help. The Solaris pkg seems to take
over a second even when doing 'pkg version' so in this case, I would
simply put a test in using $OSTYPE.

The only other name clash I'm aware of is nc (netcat or nedit client). In
that case _netcat uses _pick_variant and calls _nedit.

Oliver


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

end of thread, other threads:[~2012-09-30 20:54 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-28  9:33 Completion collision, best way to fix Baptiste Daroussin
2012-09-28 14:59 ` Bart Schaefer
2012-09-29  1:12   ` Danek Duvall
2012-09-29  1:39     ` Baptiste Daroussin
2012-09-29  1:56       ` Danek Duvall
2012-09-29  3:40       ` Bart Schaefer
2012-09-30 20:47         ` Oliver Kiddle
2012-09-29  1:53     ` Phil Pennock

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