zsh-users
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Danek Duvall <duvall@emufarm.org>
Cc: Jonas Juselius <jonas@iki.fi>, zsh-users@sunsite.dk
Subject: Re: Completion function for bitkeeper?
Date: Tue, 11 Nov 2003 09:22:57 +0100	[thread overview]
Message-ID: <9219.1068538977@gmcs3.local> (raw)
In-Reply-To: <20031110182013.GA20547@lorien.emufarm.org>

Danek Duvall wrote:

> I agree that if it's merely a convention that I shouldn't use it.
> However, the zshcompsys man page explicitly documents it, suggesting
> that it's safe to use.  If it's not, perhaps removing it from the
> documentation is the right thing to do.

Searching for expl in zshcompsys, it is only used in examples. The one
exception is in the context of _arguments actions where it isn't just a
convention (_arguments can't use positional parameters for actions). I
certainly can't see anywhere where it suggests that you can expect it
to be set by a calling function.

> Still, this whole thing feels like a fragile interface.  Two entirely
> different sets of information are being passed to the function on the
> commandline, which at the very least means that there's a potential for
> flag collision (what happens if _arguments decides to pass in -e for
> compadd purposes?), never mind the parsing difficulties.

The two entirely different sets of information system isn't ideal but
the positional parameters are the most convenient place for passing
information around.

The best alternative I can think of would be to have the tag loop
function store the compadd options for each level of tag nesting and
not use positional parameters for compadd options. Tag loops need
rethinking anyway due to problems with label loops being separate.

For now completion functions should avoid certain compadd options for
passing other information. zparseopts tends to make it easy enough to
follow this. If you really want lots of options, follow _arguments and
have a `-O array' option for passing compadd options.

> It seems that using some other method for passing in compadd arguments
> would be better ... such as using a well-known parameter name.  :)
> 
> I still maintain that passing in the compadd arguments both on the
> commandline and in $expl is a bug, as it's duplicative, redundant,
> repetitive, and redundant.

compadd arguments aren't passed in $expl. They may coincidentally
happen to be lying around in $expl but only because $expl was chosen as
a place to have _description store them temporarily before passing them
on.

Oliver


  reply	other threads:[~2003-11-11  8:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-23 16:00 Steve Borho
2003-05-23 16:01 ` Danek Duvall
2003-11-06 15:32   ` Danek Duvall
2003-11-07 19:17     ` Oliver Kiddle
2003-11-10 18:20       ` Danek Duvall
2003-11-11  8:22         ` Oliver Kiddle [this message]
2003-11-11 10:42           ` Peter Stephenson
2003-11-11 15:21             ` Oliver Kiddle
2003-11-11 15:24               ` Peter Stephenson
2003-11-11 16:13                 ` Oliver Kiddle
2003-11-11 16:23                   ` Peter Stephenson
2003-11-11 16:44                     ` Oliver Kiddle
2003-11-11 16:23           ` Danek Duvall
2003-11-11 19:06             ` Oliver Kiddle
2003-11-11 21:28               ` Danek Duvall
2003-11-14  8:04                 ` Oliver Kiddle
2003-11-14 10:47                   ` Peter Stephenson
2003-11-14 13:09                     ` Oliver Kiddle
2003-11-14 16:12                       ` Bart Schaefer
2003-11-14 16:23                         ` Peter Stephenson
2003-11-14 17:14                           ` Bart Schaefer
2003-11-14 17:01                         ` Oliver Kiddle
2003-11-14 15:46                   ` Danek Duvall
2003-11-14 21:24                     ` Danek Duvall
2003-11-17 15:47                     ` Oliver Kiddle
2003-11-17 17:51                       ` Danek Duvall
2003-11-19 10:23                         ` 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=9219.1068538977@gmcs3.local \
    --to=okiddle@yahoo.co.uk \
    --cc=duvall@emufarm.org \
    --cc=jonas@iki.fi \
    --cc=zsh-users@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).