zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk
Subject: Re: Passsing descriptions down in completion functions
Date: Thu, 09 Jan 2003 18:09:51 +0100	[thread overview]
Message-ID: <503.1042132191@finches.logica.co.uk> (raw)
In-Reply-To: <6134254DE87BD411908B00A0C99B044F04D69127@MOWD019A>

On 9 Jan, you wrote:
> 
> Well, I started to look into these functions and immediately hit some
> problems:
>
> AIX/Type/_object_classes:
> 
> _wanted objectclasses expl 'object class' \
>    _files -W ${ODMDIR:-/etc/objrepos} -g '^*.vc'
> 
> Here is just no place where I could stuff the magic "-". Granted, this one
> does not pass arguments it receives but in general I do not see why it
> should not do it.

I think you can put the "-" on the end of the line like this:
  _wanted ... \
     _files -W ${ODMDIR:-/etc/objrepos} -g '^*.vc' "$@" -

> Base/Utility/_sub_commands
> 
> if [[ CURRENT -eq 2 ]]; then
>   _wanted commands expl command compadd "$@"
> else
>   _message 'no more arguments'
> fi
> 
> almost the same problem. In this case arguments contain both description and
> matches so I have no way to stuff "-" in between.

That's a slightly unusual case because any matches passed to
_sub_commands could be thought of as not being arguments to compadd to
be passed on in the traditional sense. It is probably best handled by
passing a "-" in the calling function.

I agree that this isn't particularly ideal though. I remember Sven
saying something about rethinking the way compadd options are passed
but I was mostly thinking in terms of suffixes and not descriptions.
It'd be wise to think in terms of all the compadd options and how they
are passed around in coming up with a good solution.

A variant of your _all_labels suggestion is perhaps not a bad idea. I'd
want to be able to override any passed descriptions in some cases.

Oliver

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.


  reply	other threads:[~2003-01-09 17:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-09 16:26 Borzenkov Andrey
2003-01-09 17:09 ` Oliver Kiddle [this message]
2003-01-10  8:10   ` Borzenkov Andrey
2003-01-14 15:43     ` Oliver Kiddle
  -- strict thread matches above, loose matches on Subject: below --
2003-01-09 13:17 Borzenkov Andrey
     [not found] ` <32149.1042120127@finches.logica.co.uk>
2003-01-09 14:04   ` Oliver Kiddle
2003-01-09 15:09   ` Borzenkov Andrey
2003-01-09 16:11     ` Oliver Kiddle

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=503.1042132191@finches.logica.co.uk \
    --to=okiddle@yahoo.co.uk \
    --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).