zsh-users
 help / color / mirror / code / Atom feed
From: Peter Stephenson <Peter.Stephenson@csr.com>
To: Zsh Users <zsh-users@zsh.org>
Subject: Re: Using the same completion function for various commands
Date: Mon, 6 Dec 2010 17:08:12 +0000	[thread overview]
Message-ID: <20101206170812.7c53824b@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <101206084428.ZM2380@torch.brasslantern.com>

On Mon, 06 Dec 2010 08:44:28 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Dec 6,  4:21pm, Peter Stephenson wrote:
> }
> } Is the following change to _pick_variant right?  Why we would ever
> } prefer $words[1] to $service, when this seems to be what $service is
> } for?
> 
> My recollection is that $words[1] is always a command, whereas
> $service may just be a placeholder name.  However, I can't provide an
> example where this would introduce a problem for _pick_variant in
> particular.

Yes, for example in _perforce I use the service as p4-<subcommand>.
But, as you imply, in that case there's no question of running
_pick_variant, we've already got into the detailed syntax another way.

We can just pass -c $service to _pick_variants, it's just that that's
yet another variable factor to go wrong, so if we can avoid it that's
good.  In particular, you don't notice it's gone wrong until a case like
the one Mikael noticed --- to put it another way, the service is a
parameter that can be set by the user, and until the user tries to map a
new command to an existing completion you don't know the completion
function needed "-c $service".

Of course, if we find a case where this doesn't work, the caller can use
"-c $words[1]".  Given that I think that's the odd case out, maybe I'll
just commit it and see what happens.

(Sigh. Good job it's only Monday...)

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom


  reply	other threads:[~2010-12-06 17:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-06 14:12 Martin Richter
2010-12-06 14:54 ` Mikael Magnusson
2010-12-06 15:01   ` Jérémie Roquet
2010-12-06 15:03     ` Mikael Magnusson
2010-12-06 15:11       ` Peter Stephenson
2010-12-06 15:18         ` Mikael Magnusson
2010-12-06 16:10           ` Peter Stephenson
2010-12-06 16:21             ` Peter Stephenson
2010-12-06 16:44               ` Bart Schaefer
2010-12-06 17:08                 ` Peter Stephenson [this message]
2010-12-06 19:39           ` Oliver Kiddle
2010-12-07 11:52             ` Peter Stephenson
2010-12-06 15:23         ` Martin Richter
2010-12-06 15:31         ` Jérémie Roquet

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=20101206170812.7c53824b@pwslap01u.europe.root.pri \
    --to=peter.stephenson@csr.com \
    --cc=zsh-users@zsh.org \
    /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).