From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: Re: _arguments questions
Date: Wed, 5 Apr 2000 14:03:09 +0200 (MET DST) [thread overview]
Message-ID: <200004051203.OAA02789@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Sven Wischnowsky's message of Wed, 5 Apr 2000 11:43:20 +0200 (MET DST)
I wrote:
> Alexandre Duret-Lutz wrote:
>
> > >>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> >
> > ...
> >
> > Sven> Because of that (;-) and because it isn't quite the same (but I
> > Sven> confess, I had the same idea...). Especially, adding this dummy
> > Sven> element might be useful to combine with both `::' and `:::'.
> >
> > An helper function ?
> >
> > _with_dummy_arg0 () { # I'm not good at finding names...
> > words=(dummy $words)
> > (( ++CURRENT ))
> > $@
> > }
> >
> > _arguments -a -b '-c:*::blah: _with_dummy_arg0 _arguments -c -d -e'
>
> I thought about that, too. And then thought this could easily be put
> in _arguments, i.e. make it just look for a certain prefix in the
> action -- as if there were a function called. I couldn't find another
> use for this dummy-insertion-function...
This does that: if the action starts with `= ' (a equal sign and a
space), these will be removed from the action and the sub-context
(i.e. something like `-c-1') will be inserted as the new first element
into $words.
No need to do that in _values and _alternative...
Is the syntax weird enough?
Bye
Sven
Index: Completion/Base/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/_arguments,v
retrieving revision 1.2
diff -u -r1.2 _arguments
--- Completion/Base/_arguments 2000/04/01 20:43:43 1.2
+++ Completion/Base/_arguments 2000/04/05 12:02:19
@@ -192,6 +192,12 @@
if [[ -n "$matched" ]] || _requested arguments; then
_description arguments expl "$descr"
+ if [[ "$action" = \=\ * ]]; then
+ action="$action[3,-1]"
+ words=( "$subc" "$words[@]" )
+ (( CURRENT++ ))
+ fi
+
if [[ "$action" = -\>* ]]; then
comparguments -W line opt_args
state="${${action[3,-1]##[ ]#}%%[ ]#}"
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.7
diff -u -r1.7 compsys.yo
--- Doc/Zsh/compsys.yo 2000/04/05 11:07:26 1.7
+++ Doc/Zsh/compsys.yo 2000/04/05 12:02:22
@@ -2497,7 +2497,7 @@
using tt(_tags) and if the tag is requested, the var(action) is
executed with the given var(descr) (description). The var(action)s
supported are those used by the tt(_arguments) function (described
-below), without the `tt(->)var(state)' form.
+below), without the `tt(->)var(state)' and `tt(=)var(...)' forms.
For example, the var(action) may be a simple function call. With that
one could do:
@@ -2793,6 +2793,23 @@
are taken from the array parameter tt(expl) which will be set up
before executing the var(action) and hence may be used in it (normally
in an expansion like `tt($expl[@])').
+
+If the var(action) starts with `tt(= )' (a equal sign followed by a
+space), tt(_arguments) will insert the contents of the var(argument)
+field of the current context as the new first element in the tt(words)
+special array and increments the value of the tt(CURRENT) special
+parameter. In other words, it inserts a dummy element in the tt(words)
+array and makes tt(CURRENT) still point to the word in that array
+where the cursor is. This is only really useful when used with one of
+the forms that make tt(_arguments) modify the tt(words) array to
+contain only some of the words from the line, i.e. one of the argument
+description forms where the var(message) is preceded by two or three
+colons. For example, when the function called in the action for such
+an argument itself uses tt(_arguments), the dummy element is needed to
+make that second call to tt(_arguments) use all words from the
+restricted range for argument parsing. Without the inserted dummy
+element, the first word in the range would be taken (by the second
+tt(_arguments)) to be the command name and hence ignored.
Except for the `tt(->)var(string)' form, the var(action) will be
executed by calling the tt(_all_labels) function to process all tag labels,
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-04-05 12:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-04-05 12:03 Sven Wischnowsky [this message]
2000-04-05 13:01 ` Alexandre Duret-Lutz
-- strict thread matches above, loose matches on Subject: below --
2000-04-05 9:43 Sven Wischnowsky
2000-04-05 8:11 Sven Wischnowsky
2000-04-05 9:28 ` Alexandre Duret-Lutz
2000-04-04 12:54 Sven Wischnowsky
2000-04-04 15:59 ` Alexandre Duret-Lutz
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=200004051203.OAA02789@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.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).