Re: PATCH: Re: sudo completion problem

Re: PATCH: Re: sudo completion problem

[Sven Wischnowsky]

Zefram wrote:

> ...
> 
> If we can determine that a particular command is processing options in
> this way, it would be nice to complet options accordingly.  However,
> by default options should only be completed before the first non-option
> argument.  In either case, options should never be completed after a "--".

I don't buy this. There *may* be commands or shell functions which
take `--' to, e.g.,  separate different sets of options and arguments.

_arguments is intended to be general enough to generate sensible
completions even for user-written shell functions, after all.

Please lets not make _arguments treat any string from the line special 
like this. Lets add it to:

> I envision _arguments first of all deciding whether the command allows
> options everywhere or not.  This should be under the control of the
> caller, via options to _arguments; possible values are "everywhere",
> "only before first argument", "autodetect GNU getopt" (if possible).

So wo would have these plus these combined with `and no options after --'.

Ok?

> _arguments must also check for a "--" argument, and not do option
> completion (regardless of option style) if the cursor is after the "--".
> All of this then lets it decide whether to complete options or not;
> non-option arguments are always a possibility, though we might want to
> be clever about handling arguments that start with "-".

No patch yet, but adding an option to comparguments (the builtin) for
the second (i.e. "only before first argument" the first would still be
the default, _arguments could use a different default, I don't care
that much about it for now) should be easy. And another option for the 
"no options after `--'" would be easy, too.

But before I start writing it: should the default for _arguments be
changed? And would someone be willing to check all uses of _arguments
and add the option to the calls that need them? Oh, and does anyone
have an idea how to test for GNU-getopts. Reliably?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: optional argument?

[Sven Wischnowsky]

Tanaka Akira wrote:

> In article <200004250945.LAA03283@beta.informatik.hu-berlin.de>,
>   Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> 
> > > Because an argument for `-o' is optional, `xxx' is an argument for the
> > > option or first non-option argument.  So, the word to be completed by
> > > <TAB> is first non-option argument or second non-option argument.
> > > Hence `arg1' and `arg2' should be completed.  But I think this is bit
> > > confused and not so useful.
> > 
> > Oh, did you have to say that?
> 
> I found an example.
> 
> Z(4):akr@serein% Src/zsh -f
> serein% Src/zsh -f
> serein% bindkey -e; fpath=($PWD/Completion/*(/)); autoload -U compinit; compinit -D; compdef _tst tst
> serein% zstyle ':completion:*' group-name ''
> serein% zstyle ':completion:*:messages' format %d
> serein% zstyle ':completion:*:descriptions' format %d
> serein% diff --context ChangeLog <TAB>
> original file
> ...
> new file
> ...
> 
> This is caused by optional argument for --context.  In this position,
> _diff_options should completes only new files: second file set.  In
> general, optional argument of _arguments always causes similar
> problem, I think.  So, I think it is bit confused and not so useful.

Well, in this case it is really caused by --context not accepting its
argument in a separate word.

Hm, what are we supposed to do now? Generally making it not complete
normal arguments when in a position for an optional option-argument
wouldn't solve the problem. Making it not complete optional option-
arguments in separate words could be wrong, too, for commands that can 
find out if the argument is a normal or for the option.

Hrmpf. Make `='-options complete the argument *only* after the equal
sign? Add a new specification type, say `-opt==' for options that
don't accept the argument in a separte word (should the long-option
auto-detection code use it then?)?

I think I prefer the latter. Opinions?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: optional argument?

[Peter Stephenson]

> Hrmpf. Make `='-options complete the argument *only* after the equal
> sign? Add a new specification type, say `-opt==' for options that
> don't accept the argument in a separte word (should the long-option
> auto-detection code use it then?)?
> 
> I think I prefer the latter. Opinions?

More generally, I wonder if a good way to handle variant option syntax
might be to allow a `profile' of some sort to be passed down to arguments,
either as an option or a parameter, saying what form of options and
arguments the command in question accepts.  This keeps the rest of the
command line to arguments neater.  It can wait.  It doesn't help here if
it's really that one option that has the rogue behaviour.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: optional argument?

[Tanaka Akira]

In article <200005080944.LAA15834@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> Well, in this case it is really caused by --context not accepting its
> argument in a separate word.

Yes.  So, I used `--context=-' in _cvs for `cvs diff'.  However this
is bit annoying because `=' is not removal suffix.

> Hm, what are we supposed to do now? Generally making it not complete
> normal arguments when in a position for an optional option-argument
> wouldn't solve the problem. Making it not complete optional option-
> arguments in separate words could be wrong, too, for commands that can 
> find out if the argument is a normal or for the option.

Actual commands which has optional arguments judge whether they are
specified or not in a some criteria.  So, supporting some common
criteria is useful.

> Hrmpf. Make `='-options complete the argument *only* after the equal
> sign? Add a new specification type, say `-opt==' for options that
> don't accept the argument in a separte word (should the long-option
> auto-detection code use it then?)?

Exactly, the existence of `=' is the criteria used by getopt_long.  So
it's good.  But I vote `-opt=?' instead of `-opt=='.

Note that another common criteria is that a optional argument must be
some set of strings: `yes' or `no' for example.  At least, xset
handles optional arguments in this way.  If we can specify a pattern
addition to the current optional argument syntax, it can be handled.
However, _xset cannot use _arguments since it has more anomalies if
the optional arguments can be handled.

Apart from that, I hope a extension for _arguments.  There are 
many duplicated descriptions such as:

    ....
    '(-i)--ignore-case[case insensitive]' \
    '(--ignore-case)-i[case insensitive]' \
    '(-w)--ignore-all-space[ignore all white space]' \
    '(--ignore-all-space)-w[ignore all white space]' \
    '(-b)--ignore-space-change[ignore changes in the amount of white space]' \
    '(--ignore-space-change)-b[ignore changes in the amount of white space]' \
    '(-B)--ignore-blank-lines[ignore lines that are all blank]' \
    '(--ignore-blank-lines)-B[ignore lines that are all blank]' \
    '(-I)--ignore-matching-lines=[ignore lines that match regex]:line exclusion regex:' \
    '(--ignore-matching-lines)-I+[ignore lines that match regex]:line exclusion regex:' \
    ...

So, I really want to describe them as:

    ...
    '--ignore-case,-i[case insensitive]' \
    '--ignore-all-space,-w[ignore all white space]' \
    '--ignore-space-change,-b[ignore changes in the amount of white space]' \
    '--ignore-blank-lines,-B[ignore lines that are all blank]' \
    '--ignore-matching-lines=,-I+[ignore lines that match regex]:line exclusion regex:' \
    ...

In other words, I think it is useful that opt-spec is comma separated
list of options.  And exclusive options are automatically set up each
other if they are not prefixed as `*'.
-- 
Tanaka Akira

Assorted _arguments arguments

[Bart Schaefer]

On May 8, 11:00am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: sudo completion problem
}
} Zefram wrote:
} 
} > If we can determine that a particular command is processing options in
} > this way, it would be nice to complet options accordingly.  However,
} > by default options should only be completed before the first non-option
} > argument.  In either case, options should never be completed after a "--".
} 
} I don't buy this. There *may* be commands or shell functions which
} take `--' to, e.g., separate different sets of options and arguments.

As an example, consider writing a completer for the old compctl command,
following a -x option.

} _arguments is intended to be general enough to generate sensible
} completions even for user-written shell functions, after all.

I'm with Sven here.  I don't think making _arguments more specialized is
the right thing.  There should perhaps be a fairly trivial way to tell it
to stop completing options after a non-option argument, including `--' as
a non-option, but otherwise I think it may already even go too far in
treating words that begin with a `-' specially.

} But before I start writing it: should the default for _arguments be
} changed? And would someone be willing to check all uses of _arguments
} and add the option to the calls that need them?

I don't think it makes a lot of difference which way the default goes;
do whatever would require the fewest changes to _arguments and to all
the other functions that call it.

On May 8, 11:44am, Sven Wischnowsky wrote:
} Subject: Re: optional argument?
}
[Tanaka-san wrote:]
} > This is caused by optional argument for --context.  In this position,
} > _diff_options should completes only new files: second file set.  In
} > general, optional argument of _arguments always causes similar
} > problem, I think.  So, I think it is bit confused and not so useful.
} 
} Hrmpf. Make `='-options complete the argument *only* after the equal
} sign? Add a new specification type, say `-opt==' for options that
} don't accept the argument in a separte word (should the long-option
} auto-detection code use it then?)?

On May 8, 11:49pm, Tanaka Akira wrote:
} Subject: Re: optional argument?
}
} Actual commands which has optional arguments judge whether they are
} specified or not in a some criteria.  So, supporting some common
} criteria is useful.
} 
[...]
} 
} Exactly, the existence of `=' is the criteria used by getopt_long.  So
} it's good.  But I vote `-opt=?' instead of `-opt=='.

I think we should try to make the syntax consistent with `getopts' and
`zparseopts' if possible.  Maybe that _isn't_ possible do to conflicting
use of colons ... and maybe we should have thought of that before we used
colons everywhere, but ...

} Note that another common criteria is that a optional argument must be
} some set of strings: `yes' or `no' for example.  At least, xset
} handles optional arguments in this way.  If we can specify a pattern
} addition to the current optional argument syntax, it can be handled.

If there's a known set of strings that can be the optional argument, then
I think this can be handled with state changes and/or alternation and we
don't need any more patterns jammed into the opt-spec.

} Apart from that, I hope a extension for _arguments.  There are 
} many duplicated descriptions such as:
} 
}     '(-i)--ignore-case[case insensitive]' \
}     '(--ignore-case)-i[case insensitive]' \
}     '(-w)--ignore-all-space[ignore all white space]' \
}     '(--ignore-all-space)-w[ignore all white space]' \
} 
} So, I really want to describe them as:
} 
}     '--ignore-case,-i[case insensitive]' \
}     '--ignore-all-space,-w[ignore all white space]' \
} 
} In other words, I think it is useful that opt-spec is comma separated
} list of options.  And exclusive options are automatically set up each
} other if they are not prefixed as `*'.

On a similar topic, can anyone think of a way to write an exclusive-or
glob pattern?  E.g. I want to match ChangeLog if that exists, or Changes
if that exists, but neither if both exist?

Returning to the original topic, perhaps a better way to think of this
is that -i and --ignore-case are synonyms and should get the same
treatment and description.  E.g. your suggestion does not help with
a case like

_bzip2:    '(--decompress --compress -z --test -t)-d[decompress]' \
_bzip2:    '(-d --compress -z --test -t)--decompress[decompress]' \
_bzip2:    '(--compress --decompress -d --test -t)-z[compress]' \
_bzip2:    '(-z --decompress -d --test -t)--compress[compress]' \

where you have both options that have alternate names for each other and
are mutually exclusive with other options.  Much better would be, say,

	'-d(--decompress)' '-z(--compress)' '-t(--test)' \
	'(-z -t)-d[decompress]' \
	'(-d -t)-z[compress]' \
	'(-z -d)-t[test compressed file integrity]' \

It might even be able to compute this automatically from the comma-lists
in --help output, or some such.  (No, I don't really like the `-x(--xxx)'
syntax, but I haven't time to think harder about it just now.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Assorted _arguments arguments

[Peter Stephenson]

Bart wrote:
> On a similar topic, can anyone think of a way to write an exclusive-or
> glob pattern?  E.g. I want to match ChangeLog if that exists, or Changes
> if that exists, but neither if both exist?

I don't think this is possible.  The globbing code matches files
separately.  It would have to look at the list of files already matched to
know whether to reject both that and the new one, which is extremely
hairy.  Obviously you can do it with arrays and things.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: PATCH: Re: sudo completion problem

[Tanaka Akira]

In article <200005080900.LAA13146@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> But before I start writing it: should the default for _arguments be
> changed? And would someone be willing to check all uses of _arguments
> and add the option to the calls that need them? Oh, and does anyone
> have an idea how to test for GNU-getopts. Reliably?


0. If a completion function knows the precious command behavior, use
   the knowledge.

1. If `-s' is not specified, it's not getopt.

2. If the environment variable POSIXLY_CORRECT is set, assume
   traditional getopt.

3. If on GNU system such as Linux, assume GNU getopt.

4. If it is not cases above, assume traditional getopt.

I think this guess is not so bad.
-- 
Tanaka Akira

Re: PATCH: Re: sudo completion problem

[Sven Wischnowsky]

Tanaka Akira wrote:

> ...
> 
> My idea is already implemented: _regex_arguments.  Although currently
> there are only three completion functions - _apt, _xwit and _xset -
> which use _regex_arguments because it cannot use _arguments,  I think
> there are more completion  functions which can be written bit more
> simple if _regex_arguments is used.  Maybe, _xauth (and _cvs?).

Personally I find _arguments a whole lot more readable than
_regex_arguments. If that could be improved, I'd be glad.

Although I always wonder why people find _cvs difficult...

> ...
> 
> > And I'd like repeat once more - currently, when _arguments is using
> > lexical structure to describe semantic, it is hard to add something. If
> > we had flags ... (not suggesting breaking compatibility - but just for
> > future use).
> 
> _regex_arguments handle only parsing of arguments.  So other stuff
> handled by _arguments such as descriptions, exclusive options must be
> implemented by completion function writer.  It's bit hard task but we
> can implement special feature easily.

I would be *very* glad if _regex_arguments could at least handle the
tags, tag-labels and descriptions. I had lots of problems trying to
work those changes into the functions using _regex_arguments and since 
I don't know any of those commands I still don't know if I've got it
right.

Either in _regex_arguments or in a convenience wrapper function around 
it, of course.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Re: sudo completion problem

[Tanaka Akira]

In article <200005041340.PAA08620@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> Personally I find _arguments a whole lot more readable than
> _regex_arguments. If that could be improved, I'd be glad.

I think so too.  It is one of biggest reason that always I tried to
use _arguments.

> I would be *very* glad if _regex_arguments could at least handle the
> tags, tag-labels and descriptions. I had lots of problems trying to
> work those changes into the functions using _regex_arguments and since 
> I don't know any of those commands I still don't know if I've got it
> right.

Hm.  OK.

Index: Completion/Base/_regex_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/_regex_arguments,v
retrieving revision 1.1.1.15
diff -u -r1.1.1.15 _regex_arguments
--- Completion/Base/_regex_arguments	2000/03/24 11:29:19	1.1.1.15
+++ Completion/Base/_regex_arguments	2000/05/04 20:03:10
@@ -68,8 +68,9 @@
 
   eval \
   "$funcname"' () {
-    local _ra_p1 _ra_p2 _ra_left _ra_right _ra_com
+    local _ra_p1 _ra_p2 _ra_left _ra_right _ra_com expl tmp nm="$compstate[nmatches]"
     local _ra_actions _ra_line="${(pj:\0:)${(@)words[1,CURRENT - 1]:Q}}"$'\''\0'\''"$PREFIX"
+    _ra_actions=()
     zregexparse -c _ra_p1 _ra_p2 "$_ra_line" '"${(j: :)${(qqqq)regex[@]}}"'
     case "$?" in
     0|2) _message "no more arguments";;
@@ -80,13 +81,26 @@
 	_ra_left="$_ra_line[_ra_p1 + 1, _ra_p2]"
 	_ra_right="$_ra_line[_ra_p2 + 1, -1]"
 	compset -p $(( $#PREFIX - $#_ra_line + $_ra_p1 ))
-	for _ra_com in "$_ra_actions[@]"; do
-	  eval "$_ra_com"
-	done
+	: "$_ra_actions[@]"
+	tmp=("${(@)_ra_actions%%:*}")
+	if (( $#tmp )); then
+	  _tags "$tmp[@]"
+	  while _tags; do
+	    for _ra_com in "$_ra_actions[@]"; do
+	      if _requested "${_ra_com%%:*}"; then
+		while _next_label "${_ra_com%%:*}" expl "${${_ra_com#*:}%%:*}"; do
+		  eval "${_ra_com#*:*:}"
+		done
+		[[ nm -ne "$compstate[nmatches]" ]] && break 2
+	      fi
+	    done
+	  done
+	fi
       fi
       ;;
     3) _message "invalid regex";;
     esac
+    [[ nm -ne "$compstate[nmatches]" ]]
   }'
 }
 
Index: Completion/Debian/_apt
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Debian/_apt,v
retrieving revision 1.3
diff -u -r1.3 _apt
--- Completion/Debian/_apt	2000/04/11 07:57:57	1.3
+++ Completion/Debian/_apt	2000/05/04 20:03:10
@@ -75,9 +75,9 @@
   nul=$'\0'
   qnul="\$'\\0'"
 
-  comp_bool='_wanted values expl_bool "boolean value" compadd "$expl_bool[@]" '"$bool"
+  comp_bool='compadd "$expl[@]" '"$bool"
   comp_intlevel= #"_message 'intlevel'"
-  comp_configfile='_files "$expl_configfile[@]"'
+  comp_configfile='_files "$expl[@]"'
   comp_arbitem= #"_message 'Foo::Bar=bar'"
 
   comp_short=\
@@ -116,15 +116,15 @@
     regex_short=("$regex_short[@]"
       /"$short_seq(${(j:|:)short_hasarg})(=|)"/
 	-'_apt_consume_short ${match[1]%=}; current_option=${canonicalize[-${${match[1]%=}[-1]}]}'
-	\( /"$word1"/ :"$comp_hasarg" \| /"$nul"/ /"$word"/ :"$comp_hasarg" \) \|
+	\( /"$word1"/ ":options:option:$comp_hasarg" \| /"$nul"/ /"$word"/ ":options:option:$comp_hasarg" \) \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)short_hasarg})$nul"/
 	-'_apt_consume_short ${match[1][-2]}; current_option=${canonicalize[-${${match[1]%'$qnul'}[-1]}]}'
-	/"$word"/ :"$comp_hasarg" \|
+	/"$word"/ ":options:option:$comp_hasarg" \|
       /"(${(j:|:)short_hasarg})="/
 	-'_apt_consume_short ${match[1][-2]}; current_option=${canonicalize[-${${match[1]%=}[-1]}]}'
-	\( /"$word1"/ :"$comp_hasarg" \| /"$nul"/ /"$word"/ :"$comp_hasarg" \) \|
+	\( /"$word1"/ ":options:option:$comp_hasarg" \| /"$nul"/ /"$word"/ ":options:option:$comp_hasarg" \) \|
     )
   fi
 
@@ -134,15 +134,15 @@
 	-'_apt_consume_short ${match[1]%%('$qnul'('${(j:|:)bool}')|('${(j:|:)bool}')|)'$qnul'}' \|
       /"$short_seq(${(j:|:)short_bool})="/
 	-'_apt_consume_short ${match[1]%=}'
-	\( /"$word1"/ :"$comp_bool" \| /"$nul"/ /"$word"/ :"$comp_bool" \) \|
+	\( /"$word1"/ ":names:boolean value:$comp_bool" \| /"$nul"/ /"$word"/ ":names:boolean value:$comp_bool" \) \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)short_bool})="/
 	-'_apt_consume_short ${match[1][-2]}'
-	\( /"$word1"/ :"$comp_bool" \| /"$nul"/ /"$word"/ :"$comp_bool" \) \|
+	\( /"$word1"/ ":names:boolean value:$comp_bool" \| /"$nul"/ /"$word"/ ":names:boolean value:$comp_bool" \) \|
       /"(${(j:|:)short_bool})$nul"/
 	-'_apt_consume_short ${match[1][-2]}'
-	/"((${(j:|:)bool})$nul|)"/ :"$comp_bool" \|
+	/"((${(j:|:)bool})$nul|)"/ ":names:boolean value:$comp_bool" \|
     )
   fi
 
@@ -152,15 +152,15 @@
 	-'_apt_consume_short ${match[1]%%'"($qnul$intlevel|$intlevel|)$qnul"'}' \|
       /"$short_seq(${(j:|:)short_intlevel})="/
 	-'_apt_consume_short ${match[1]%=}'
-	\( /"$word1"/ :"$comp_intlevel" \| /"$nul"/ /"$word"/ :"$comp_intlevel" \) \|
+	\( /"$word1"/ ":options:option:$comp_intlevel" \| /"$nul"/ /"$word"/ ":options:option:$comp_intlevel" \) \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)short_intlevel})="/
 	-'_apt_consume_short ${match[1][-2]}'
-	\( /"$word1"/ :"$comp_intlevel" \| /"$nul"/ /"$word"/ :"$comp_intlevel" \) \|
+	\( /"$word1"/ ":options:option:$comp_intlevel" \| /"$nul"/ /"$word"/ ":options:option:$comp_intlevel" \) \|
       /"(${(j:|:)short_intlevel})$nul"/
 	-'_apt_consume_short ${match[1][-2]}'
-	/"($intlevel$nul|)"/ :"$comp_intlevel" \|
+	/"($intlevel$nul|)"/ ":options:option:$comp_intlevel" \|
     )
   fi
 
@@ -168,15 +168,15 @@
     regex_short=("$regex_short[@]"
       /"$short_seq(${(j:|:)short_configfile})(=|)"/
 	-'_apt_consume_short ${match[1]%=}'
-	\( /"$word1"/ :"$comp_configfile" \| /"$nul"/ /"$word"/ :"$comp_configfile" \) \|
+	\( /"$word1"/ ":files:config file:$comp_configfile" \| /"$nul"/ /"$word"/ ":files:config file:$comp_configfile" \) \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)short_configfile})$nul"/
 	-'_apt_consume_short ${match[1][-2]}'
-	/"$word"/ :"$comp_configfile" \|
+	/"$word"/ ":files:config file:$comp_configfile" \|
       /"(${(j:|:)short_configfile})="/
 	-'_apt_consume_short ${match[1][-2]}'
-	\( /"$word1"/ :"$comp_configfile" \| /"$nul"/ /"$word"/ :"$comp_configfile" \) \|
+	\( /"$word1"/ ":files:config file:$comp_configfile" \| /"$nul"/ /"$word"/ ":files:config file:$comp_configfile" \) \|
     )
   fi
 
@@ -184,15 +184,15 @@
     regex_short=("$regex_short[@]"
       /"$short_seq(${(j:|:)short_arbitem})(=|)"/
 	-'_apt_consume_short ${match[1]%=}'
-	\( /"$word1"/ :"$comp_arbitem" \| /"$nul"/ /"$word"/ :"$comp_arbitem" \) \|
+	\( /"$word1"/ ":options:option:$comp_arbitem" \| /"$nul"/ /"$word"/ ":options:option:$comp_arbitem" \) \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)short_arbitem})$nul"/
 	-'_apt_consume_short ${match[1][-2]}'
-	/"$word"/ :"$comp_arbitem" \|
+	/"$word"/ ":options:option:$comp_arbitem" \|
       /"(${(j:|:)short_arbitem})="/
 	-'_apt_consume_short ${match[1][-2]}'
-	\( /"$word1"/ :"$comp_arbitem" \| /"$nul"/ /"$word"/ :"$comp_arbitem" \) \|
+	\( /"$word1"/ ":options:option:$comp_arbitem" \| /"$nul"/ /"$word"/ ":options:option:$comp_arbitem" \) \|
     )
   fi
 
@@ -200,18 +200,18 @@
     regex_long=("$regex_long[@]"
       /"(${(j:|:)long_hasarg})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}; current_option=${canonicalize[--${match[1]%'$qnul'}]}'
-	/"$word"/ :"$comp_hasarg" \|
+	/"$word"/ ":options:option:$comp_hasarg" \|
       /"(${(j:|:)long_hasarg})="/
 	-'_apt_consume_long ${match[1]%=}; current_option=${canonicalize[--${match[1]%=}]}'
-	\( /"$word1"/ :"$comp_hasarg" \| /"$nul"/ /"$word"/ :"$comp_hasarg" \) \|
+	\( /"$word1"/ ":options:option:$comp_hasarg" \| /"$nul"/ /"$word"/ ":options:option:$comp_hasarg" \) \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)long_hasarg})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}; current_option=${canonicalize[--${match[1]%'$qnul'}]}'
-	/"$word"/ :"$comp_hasarg" \|
+	/"$word"/ ":options:option:$comp_hasarg" \|
       /"(${(j:|:)long_hasarg})="/
 	-'_apt_consume_long ${match[1]%=}; current_option=${canonicalize[--${match[1]%=}]}'
-	\( /"$word1"/ :"$comp_hasarg" \| /"$nul"/ /"$word"/ :"$comp_hasarg" \) \|
+	\( /"$word1"/ ":options:option:$comp_hasarg" \| /"$nul"/ /"$word"/ ":options:option:$comp_hasarg" \) \|
     )
   fi
 
@@ -219,18 +219,18 @@
     regex_long=("$regex_long[@]"
       /"(${(j:|:)long_bool})="/
 	-'_apt_consume_long ${match[1]%=}'
-	\( /"$word1"/ :"$comp_bool" \| /"$nul"/ /"$word"/ :"$comp_bool" \) \|
+	\( /"$word1"/ ":names:boolean value:$comp_bool" \| /"$nul"/ /"$word"/ ":names:boolean value:$comp_bool" \) \|
       /"(${(j:|:)long_bool})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}'
-	/"((${(j:|:)bool})$nul|)"/ :"$comp_bool" \|
+	/"((${(j:|:)bool})$nul|)"/ ":names:boolean value:$comp_bool" \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)long_bool})="/
 	-'_apt_consume_long ${match[1]%=}'
-	\( /"$word1"/ :"$comp_bool" \| /"$nul"/ /"$word"/ :"$comp_bool" \) \|
+	\( /"$word1"/ ":names:boolean value:$comp_bool" \| /"$nul"/ /"$word"/ ":names:boolean value:$comp_bool" \) \|
       /"(${(j:|:)long_bool})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}'
-	/"((${(j:|:)bool})$nul|)"/ :"$comp_bool" \|
+	/"((${(j:|:)bool})$nul|)"/ ":names:boolean value:$comp_bool" \|
     )
   fi
 
@@ -238,18 +238,18 @@
     regex_long=("$regex_long[@]"
       /"(${(j:|:)long_intlevel})="/
 	-'_apt_consume_long ${match[1]%=}'
-	\( /"$word1"/ :"$comp_intlevel" \| /"$nul"/ /"$word"/ :"$comp_intlevel" \) \|
+	\( /"$word1"/ ":options:option:$comp_intlevel" \| /"$nul"/ /"$word"/ ":options:option:$comp_intlevel" \) \|
       /"(${(j:|:)long_intlevel})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}'
-	/"($intlevel$nul|)"/ :"$comp_intlevel" \|
+	/"($intlevel$nul|)"/ ":options:option:$comp_intlevel" \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)long_intlevel})="/
 	-'_apt_consume_long ${match[1]%=}'
-	\( /"$word1"/ :"$comp_intlevel" \| /"$nul"/ /"$word"/ :"$comp_intlevel" \) \|
+	\( /"$word1"/ ":options:option:$comp_intlevel" \| /"$nul"/ /"$word"/ ":options:option:$comp_intlevel" \) \|
       /"(${(j:|:)long_intlevel})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}'
-	/"($intlevel$nul|)"/ :"$comp_intlevel" \|
+	/"($intlevel$nul|)"/ ":options:option:$comp_intlevel" \|
     )
   fi
 
@@ -257,18 +257,18 @@
     regex_long=("$regex_long[@]"
       /"(${(j:|:)long_configfile})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}'
-	/"$word"/ :"$comp_configfile" \|
+	/"$word"/ ":files:config file:$comp_configfile" \|
       /"(${(j:|:)long_configfile})="/
 	-'_apt_consume_long ${match[1]%=}'
-	\( /"$word1"/ :"$comp_configfile" \| /"$nul"/ /"$word"/ :"$comp_configfile" \) \|
+	\( /"$word1"/ ":files:config file:$comp_configfile" \| /"$nul"/ /"$word"/ ":files:config file:$comp_configfile" \) \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)long_configfile})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}'
-	/"$word"/ :"$comp_configfile" \|
+	/"$word"/ ":files:config file:$comp_configfile" \|
       /"(${(j:|:)long_configfile})="/
 	-'_apt_consume_long ${match[1]%=}'
-	\( /"$word1"/ :"$comp_configfile" \| /"$nul"/ /"$word"/ :"$comp_configfile" \) \|
+	\( /"$word1"/ ":files:config file:$comp_configfile" \| /"$nul"/ /"$word"/ ":files:config file:$comp_configfile" \) \|
     )
   fi
 
@@ -276,18 +276,18 @@
     regex_long=("$regex_long[@]"
       /"(${(j:|:)long_arbitem})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}'
-	/"$word"/ :"$comp_arbitem" \|
+	/"$word"/ ":options:option:$comp_arbitem" \|
       /"(${(j:|:)long_arbitem})="/
 	-'_apt_consume_long ${match[1]%=}'
-	\( /"$word1"/ :"$comp_arbitem" \| /"$nul"/ /"$word"/ :"$comp_arbitem" \) \|
+	\( /"$word1"/ ":options:option:$comp_arbitem" \| /"$nul"/ /"$word"/ ":options:option:$comp_arbitem" \) \|
     )
     regex_long_prefix=("$regex_long_prefix[@]"
       /"(${(j:|:)long_arbitem})$nul"/
 	-'_apt_consume_long ${match[1]%'$qnul'}'
-	/"$word"/ :"$comp_arbitem" \|
+	/"$word"/ ":options:option:$comp_arbitem" \|
       /"(${(j:|:)long_arbitem})="/
 	-'_apt_consume_long ${match[1]%=}'
-	\( /"$word1"/ :"$comp_arbitem" \| /"$nul"/ /"$word"/ :"$comp_arbitem" \) \|
+	\( /"$word1"/ ":options:option:$comp_arbitem" \| /"$nul"/ /"$word"/ ":options:option:$comp_arbitem" \) \|
     )
   fi
 
@@ -296,9 +296,9 @@
     \( /--/+ \( "$regex_long[@]"
 		/"(${(j:|:)bool})-"/+
 		  \( "$regex_long_prefix[@]"
-		     /"[]"/ :"$comp_long_prefix" \) \) \|
+		     /"[]"/ ":options:option:$comp_long_prefix" \) \) \|
        /-/+ \( "$regex_short[@]" /"[]"/ \) \|
-       /"[]"/ :"$comp_opt" \) \#
+       /"[]"/ ":options:option:$comp_opt" \) \#
     "$regex_all[@]"
   )
 
@@ -324,11 +324,6 @@
     long_arbitem=($long_arbitem)
     bool_prefix=($bool_prefix)
 
-    local expl_opt expl_bool expl_configfile
-    _description options expl_opt option
-    _description values expl_bool 'boolean value'
-    _description files expl_configfile 'config file'
-
     local current_option tmp1 tmp2 tmp3
 
     ${funcname}_sm
@@ -375,16 +370,16 @@
     -- \
     /$'update\0'/ \| \
     /$'upgrade\0'/ \| \
-    /$'install\0'/ /$'[^\0]#\0'/ :'_deb_packages "$expl_packages[@]" uninstalled || _deb_packages "$expl_packages[@]" installed' \# \| \
-    /$'remove\0'/ /$'[^\0]#\0'/ :'_deb_packages "$expl_packages[@]" installed' \# \| \
+    /$'install\0'/ /$'[^\0]#\0'/ ':packages::_deb_packages "$expl_packages[@]" uninstalled || _deb_packages "$expl_packages[@]" installed' \# \| \
+    /$'remove\0'/ /$'[^\0]#\0'/ ':packages::_deb_packages "$expl_packages[@]" installed' \# \| \
     /$'dist-upgrade\0'/ \| \
     /$'dselect-upgrade\0'/ \| \
     /$'clean\0'/ \| \
     /$'autoclean\0'/ \| \
     /$'check\0'/ \| \
-    /$'source\0'/ /$'[^\0]#\0'/ :'_deb_packages "$expl_packages[@]" avail' \# \| \
+    /$'source\0'/ /$'[^\0]#\0'/ ':packages::_deb_packages "$expl_packages[@]" avail' \# \| \
     /$'help\0/' \| \
-    /"[]"/	:'_wanted actions expl_action action compadd update upgrade install remove dist-upgrade dselect-upgrade clean autoclean check source help'
+    /"[]"/	':argument-1::compadd "$expl_action[@]" update upgrade install remove dist-upgrade dselect-upgrade clean autoclean check source help'
 
   _apt-get () {
     local expl_action expl_packages
@@ -411,18 +406,18 @@
     -o,--option:arbitem \
     -- \
     /$'help\0'/ \| \
-    /$'add\0'/ /$'[^\0]#\0'/ :'_files' \# \| \
+    /$'add\0'/ /$'[^\0]#\0'/ ':files:index files:_files "$expl[@]"' \# \| \
     /$'gencaches\0'/ \| \
-    /$'showpkg\0'/ /$'[^\0]#\0'/ :'_deb_packages "$expl_packages[@]" avail' \# \| \
+    /$'showpkg\0'/ /$'[^\0]#\0'/ ':packages::_deb_packages "$expl_packages[@]" avail' \# \| \
     /$'stats\0'=$status[4]/ \| \
     /$'dump\0'/ \| \
     /$'dumpavail\0'/ \| \
     /$'unmet\0'/ \| \
     /$'check\0'/ \| \
-    /$'search\0'/ /$'[^\0]#\0'/ :'_message "pattern"' \| \
-    /$'show\0'/ /$'[^\0]#\0'/ :'_deb_packages "$expl_packages[@]" avail' \# \| \
+    /$'search\0'/ /$'[^\0]#\0'/ ':strings::_message "pattern"' \| \
+    /$'show\0'/ /$'[^\0]#\0'/ ':packages::_deb_packages "$expl_packages[@]" avail' \# \| \
     /$'depends\0'/ \| \
-    /"[]"/ :'_wanted actions expl_action action compadd help add gencaches showpkg stats dump dumpavail unmet check search show depends'
+    /"[]"/ ':argument-1::compadd "$expl_action[@]" help add gencaches showpkg stats dump dumpavail unmet check search show depends'
 
   _apt-cache () {
     local expl_action expl_packages expl_pkg_cache expl_src_cache
@@ -451,7 +446,7 @@
     -o,--option:arbitem \
     -- \
     /$'add\0'/ \| \
-    /"[]"/	:'_wanted actions expl_action action compadd add'
+    /"[]"/	':argument-1::compadd "$expl_action[@]" add'
 
   _apt-cdrom () {
     local expl_action expl_mount_point
@@ -465,7 +460,7 @@
 }
 
 _apt-config () {
-  _apt_arguments _apt-config_sm \
+  _apt_arguments _apt-config \
     -h,--help:bool \
     -v,--version:bool \
     -c,--config-file:configfile \
@@ -473,20 +468,11 @@
     -- \
     /$'shell\0'/ \
       \( \
-	/$'[^\0]#\0'/ :'_wanted parameters expl_shell_var "shell variable to assign" compadd - "${(@k)parameters}"' \
-	/$'[^\0]#\0'/ :'_wanted configuration-keys expl_config_key "configuration key" compadd - ${${(f)"$(apt-config dump 2>&1)"}% *}' \
+	/$'[^\0]#\0'/ ':parameters:shell variable to assign:compadd "$expl[@]" - "${(@k)parameters}"' \
+	/$'[^\0]#\0'/ ':values:configuration key:compadd "$expl[@]" - ${${(f)"$(apt-config dump 2>&1)"}% *}' \
       \) \# \| \
     /$'dump\0'/ \| \
-    /"[]"/	:'_wanted actions expl_action action compadd shell dump'
-
-  _apt-config () {
-    local expl_action expl_shell_var expl_config_key
-    _description actions expl_action 'action'
-    _description parameters expl_shell_var 'shell variable to assign'
-    _description configuration-keys expl_config_key 'configuration key'
-
-    _apt-config_sm
-  }
+    /"[]"/	':argument-1:action:compadd "$expl[@]" shell dump'
 
   _apt-config "$@"
 }
Index: Completion/X/_xset
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/_xset,v
retrieving revision 1.1
diff -u -r1.1 _xset
--- Completion/X/_xset	2000/04/26 08:31:20	1.1
+++ Completion/X/_xset	2000/05/04 20:03:10
@@ -32,11 +32,11 @@
 }
 
 _xset_compfpadd () {
-  _wanted directories expl directory _files -/
+  _files "$expl[@]" -/
 }
 
 _xset_compfpdel () {
-  _wanted directories expl directory compadd - ${(s:,:)${"$(xset q)"##*
+  compadd "$expl[@]" - ${(s:,:)${"$(xset q)"##*
 Font Path:
  #}%%
 *}
@@ -44,69 +44,70 @@
 
 _regex_arguments _xset_parse \
   "/$word/" \
-  \( "/-d(isplay|)$nul/" "$guard" "/$word/" ":_x_display" \
+  \( "/-d(isplay|)$nul/" "$guard" "/$word/" ':option-display:display:_x_display "$expl[@]"' \
   \| "/-c$nul/" "$guard" \
   \| "/c$nul/" "$guard" \
-    \( "/(on|off)$nul/" ':_wanted values expl click compadd on off' \
-    \| "/[0-9]##$nul/" ':_message volume' \
+    \( "/(on|off)$nul/" ':option-c-bool:click:compadd "$expl[@]" on off' \
+    \| "/[0-9]##$nul/" ':option-c-volume:volume:_message volume' \
     \| \) \
   \| "/-b$nul/" "$guard" \
   \| "/b$nul/" "$guard" \
-    \( "/(on|off)$nul/" ':_wanted values expl bell compadd on off' \
-    \| "/[0-9]##$nul/" ':_message volume' \
-      \( "/[0-9]##$nul/" ':_message pitch' \
-	\( "/[0-9]##$nul/" ':_message duration' \
+    \( "/(on|off)$nul/" ':option-b-bool:bell:compadd "$expl[@]" on off' \
+    \| "/[0-9]##$nul/" ':option-b-volume:bell volume:_message volume' \
+      \( "/[0-9]##$nul/" ':option-b-pitch:bell pitch:_message pitch' \
+	\( "/[0-9]##$nul/" ':option-b-duration:bell duration:_message duration' \
 	\| \) \
       \| \) \
     \| \) \
   \| "/bc$nul/" "$guard" \
   \| "/-bc$nul/" "$guard" \
-  \| "/fp$nul/" "$guard" "/$word/" ':_wanted values expl "font path" compadd default rehash' \
-  \| "/(fp[+=]|[+]fp)$nul/" "$guard" "/$word/" ':compset -P "*,"; _xset_compfpadd' \
-  \| "/(fp-|-fp)$nul/" "$guard" "/$word/" ':compset -P "*,"; _xset_compfpdel' \
+  \| "/fp$nul/" "$guard" "/$word/" ':option-fp:font path:compadd "$expl[@]" default rehash' \
+  \| "/(fp[+=]|[+]fp)$nul/" "$guard" "/$word/" ':option-fp-add:font path:compset -P "*,"; _xset_compfpadd' \
+  \| "/(fp-|-fp)$nul/" "$guard" "/$word/" ':option-fp-del:font path:compset -P "*,"; _xset_compfpdel' \
   \| "/-led$nul/" "$guard" \
-    \( "/[0-9]##$nul/" ':_message integer' \
+    \( "/[0-9]##$nul/" ':option-led-number:led number:_message "led number"' \
     \| \) \
   \| "/led$nul/" "$guard" \
-    \( "/(on|off)$nul/" ':_wanted values expl led compadd on off' \
-    \| "/[0-9]##$nul/" ':_message integer' \
+    \( "/(on|off)$nul/" ':option-led-bool:led:compadd "$expl[@]" on off' \
+    \| "/[0-9]##$nul/" ':option-led-number:led number:_message "led number"' \
     \| \) \
   \| "/m(ouse|)$nul/" "$guard" \
-    \( "/default$nul/" ':_wanted values expl "mouse parameter" compadd default' \
-    \| "/[0-9]##(/[0-9]##|)$nul/" ':_message accel_mult/accel_div' \
-      \( "/[0-9]##$nul/" ':_message threshold' \
+    \( "/default$nul/" ':option-mouse-default:mouse parameter:compadd "$expl[@]" default' \
+    \| "/[0-9]##(/[0-9]##|)$nul/" ':option-mouse-mult-div:accel_mult/accel_div:_message accel_mult/accel_div' \
+      \( "/[0-9]##$nul/" ':option-mouse-threshold:threshold:_message threshold' \
       \| \) \
     \| \) \
   \| "/[-+]dpms$nul/" "$guard" \
   \| "/dpms$nul/" "$guard" \
-    \( "/[0-9]##$nul/" ':_message "standby timeout"' \
-      \( "/[0-9]##$nul/" ':_message "suspend timeout"' \
-	\( "/[0-9]##$nul/" ':_message "off timeout"' \
+    \( "/[0-9]##$nul/" ':option-dpms-standby:standby timeout:_message "standby timeout"' \
+      \( "/[0-9]##$nul/" ':option-dpms-suspend:suspend timeout:_message "suspend timeout"' \
+	\( "/[0-9]##$nul/" ':option-dpms-off:off timeout:_message "off timeout"' \
 	\| \) \
       \| \) \
-    \| "/(on|standby|suspend|off)$nul/" ':_wanted values expl DPMS compadd on standby suspend off' \
+    \| "/force/" ':option-dpms-force:force DPMS state:compadd "$expl[@]" force' \
+       "/(on|standby|suspend|off)$nul/" ':option-dpms-state:DPMS state:compadd "$expl[@]" on standby suspend off' \
     \) \
   \| "/s$nul/" "$guard" \
     \( "/(blank|noblank|expose|noexpose|default|on|activate|reset)$nul/" \
-       ':_wanted values expl "screen saver" compadd blank noblank expose noexpose default on activate reset off' \
-    \| "/off$nul/" \( "/off$nul/" ':compadd off' \| \) \
-    \| "/[0-9]##$nul/" ':_message length' \
-      \( "/[0-9]##$nul/" ':_message period' \
+       ':option-s:screen saver:compadd "$expl[@]" blank noblank expose noexpose default on activate reset off' \
+    \| "/off$nul/" \( "/off$nul/" ':option-s-off-period:period off:compadd "$expl[@]" off' \| \) \
+    \| "/[0-9]##$nul/" ':option-s-timeout:length:_message length' \
+      \( "/[0-9]##$nul/" ':option-s-period:period:_message period' \
       \| \) \
     \| \) \
   \| "/-r$nul/" "$guard" \
-    \( "/[0-9]##$nul/" ':_message keycode' \
+    \( "/[0-9]##$nul/" ':option-r-keycode:keycode:_message keycode' \
     \| \) \
   \| "/r$nul/" "$guard" \
-    \( "/(on|off)$nul/" ':_wanted values expl autorepeat compadd on off' \
-    \| "/[0-9]##$nul/" ':_message keycode' \
+    \( "/(on|off)$nul/" ':option-r-autorepeat:autorepeat:compadd "$expl[@]" on off' \
+    \| "/[0-9]##$nul/" ':option-r-keycode:keycode:_message keycode' \
     \| \) \
   \| "/p$nul/" "$guard" \
-    "/[0-9]##$nul/" ':_message pixel' \
-    "/$word/" ':_x_color' \
+    "/[0-9]##$nul/" ':option-p-pixel:pixel:_message pixel' \
+    "/$word/" ':option-p-color:color:_x_color "$expl[@]"' \
   \| "/(-|)k$nul/" "$guard" \
   \| "/(-|)q$nul/" "$guard" \
-  \| "/[]/" ':_xset_compopts' \
+  \| "/[]/" ':options:options:_xset_compopts' \
   \) \#
 
 _xset () {
Index: Completion/X/_xwit
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/_xwit,v
retrieving revision 1.3
diff -u -r1.3 _xwit
--- Completion/X/_xwit	2000/04/11 07:57:57	1.3
+++ Completion/X/_xwit	2000/05/04 20:03:11
@@ -15,34 +15,53 @@
 }
 
 _xwit_compopts () {
-  local expl
-  _wanted options expl option compadd - ${(k)no[(R)*~0]} ||
-      _wanted options expl option compadd - ${(k)no}
+  compadd "$expl[@]" - ${(k)no[(R)*~0]} ||
+    compadd "$expl[@]" - ${(k)no}
 }
 
 _regex_arguments _xwit_parse \
   "/$word/" \
   \( \
     "/-/+" \
-    \( "/display$nul/" "$guard" "/$word/" ":_x_display" \
+    \( "/display$nul/" "$guard" "/$word/" ':option-display:display:_x_display' \
     \| "/(sync|pop|open|iconify|unmap|root|current|select|(no|)(save|backingstore|saveunder))$nul/" "$guard" \
-    \| "/resize$nul/" "$guard" "/$word/" ":_message width" "/$word/" ":_message height" \
-    \| "/rows$nul/" "$guard" "/$word/" ":_message rows" \
-    \| "/columns$nul/" "$guard" "/$word/" ":_message columns" \
-    \| "/(r|)move$nul/" "$guard" "/$word/" ":_message x" "/$word/" ":_message y" \
-    \| "/(r|)warp$nul/" "$guard" "/$word/" ":_message x" "/$word/" ":_message y" \
-    \| "/colormap$nul/" "$guard" "/$word/" ":_x_colormapid" \
-    \| "/(name|label)$nul/" "$guard" "/$word/" ":_x_name" \
-    \| "/iconname$nul/" "$guard" "/$word/" ":_x_name" \
-    \| "/bitmap$nul/" "$guard" "/$word/" ":_files -g \\*.xbm" \
-    \| "/mask$nul/" "$guard" "/$word/" ":_files -g \\*.xbm" \
-    \| "/iconmove$nul/" "$guard" "/$word/" ":_message x" "/$word/" ":_message y" \
-    \| "/id$nul/" "$guard" "/$word/" ":_x_window" \
+    \| "/resize$nul/" "$guard" \
+       "/$word/" ':option-resize-width:width:_message width' \
+       "/$word/" ':option-resize-height:height:_message height' \
+    \| "/rows$nul/" "$guard" "/$word/" ':option-rows:rows:_message rows' \
+    \| "/columns$nul/" "$guard" "/$word/" ':option-columns:columns:_message columns' \
+    \| "/move$nul/" "$guard" \
+       "/$word/" ':option-move-x:x:_message x' \
+       "/$word/" ':option-move-y:y:_message y' \
+    \| "/rmove$nul/" "$guard" \
+       "/$word/" ':option-rmove-x:x:_message x' \
+       "/$word/" ':option-rmove-y:y:_message y' \
+    \| "/warp$nul/" "$guard" \
+       "/$word/" ':option-warp-x:x:_message x' \
+       "/$word/" ':option-warp-y:y:_message y' \
+    \| "/rwarp$nul/" "$guard" \
+       "/$word/" ':option-rwarp-x:x:_message x' \
+       "/$word/" ':option-rwarp-y:y:_message y' \
+    \| "/colormap$nul/" "$guard" \
+       "/$word/" ':option-colormap:colormapid:_x_colormapid' \
+    \| "/(name|label)$nul/" "$guard" \
+       "/$word/" ':option-name:name:_x_name "$expl[@]"' \
+    \| "/iconname$nul/" "$guard" \
+       "/$word/" ':option-name:iconname:_x_name "$expl[@]"' \
+    \| "/bitmap$nul/" "$guard" \
+       "/$word/" ':option-bitmap:bitmap file:_files "$expl[@]" -g \*.xbm' \
+    \| "/mask$nul/" "$guard" \
+       "/$word/" ':option-mask:mask file:_files "$expl[@]" -g \*.xbm' \
+    \| "/iconmove$nul/" "$guard" \
+       "/$word/" ':option-iconmove-x:x:_message x' \
+       "/$word/" ':option-iconmove-y:y:_message y' \
+    \| "/id$nul/" "$guard" "/$word/" ':option-id:window id:_x_window' \
     \| "/(no|)keyrepeat$nul/" "$guard" \
-        \( "/[0-9]##$nul/" ":[[ -prefix [0-9]# ]] && _message keycode" \
-	  \( "/-$nul/" "/[0-9]##$nul/" ":[[ -prefix [0-9]# ]] && _message 'last keycode'" \| \) \) \# \
-    \| "/names$nul/" "$guard" "/$word/" ":_x_window -n" \# \
-    \| "/[]/" ':_xwit_compopts' \
+        \( "/[0-9]##$nul/" ':option-keyrepeat-keycode:keycode:[[ -prefix [0-9]# ]] && _message keycode' \
+	  \( "/-$nul/" "/[0-9]##$nul/" ':option-keyrepeat-last-keycode:last keycode:[[ -prefix [0-9]# ]] && _message "last keycode"' \| \) \) \# \
+    \| "/names$nul/" "$guard" \
+       "/$word/" ':option-names:window name:_x_window -n' \# \
+    \| "/[]/" ':options:option:_xwit_compopts' \
     \) \
   \) \#
 
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.33
diff -u -r1.33 compsys.yo
--- Doc/Zsh/compsys.yo	2000/05/04 07:44:21	1.33
+++ Doc/Zsh/compsys.yo	2000/05/04 20:03:11
@@ -3276,7 +3276,7 @@
 should be quoted.
 
 startitem()
-item(tt(/)var(pattern)tt(/) [tt(%)var(lookahead)tt(%)] [tt(-)var(guard)] [tt(:)var(action)])(
+item(tt(/)var(pattern)tt(/) [tt(%)var(lookahead)tt(%)] [tt(-)var(guard)] [tt(:)var(tag)tt(:)var(descr)tt(:)var(action)])(
 This is a primitive element, corresponding to one
 state of the compiled state machine.  The state is entered if
 `tt((#b)LPAR()(#B))var(pattern)tt(RPAR()(#B))var(lookahead)tt(*)' matches
@@ -3295,12 +3295,15 @@
 command line string and var(action)s for the target are evaluated.
 In this case, nothing is actually removed from the command line string
 so that any previous or neighbouring state may also have var(actions)s.
+var(actions)s evaluation are ordered by the tt(tag-order) style and
+specified var(tag).  var(descr) is used for set up the array parameter
+tt(expl).
 )
-item(tt(/)var(pattern)tt(/+) [tt(%)var(lookahead)tt(%)] [tt(-)var(guard)] [tt(:)var(action)])(
+item(tt(/)var(pattern)tt(/+) [tt(%)var(lookahead)tt(%)] [tt(-)var(guard)] [tt(:)var(tag)tt(:)var(descr)tt(:)var(action)])(
 This is similar to `tt(/)var(pattern)tt(/) ...' but the left part of
 command line string is also considered as part of the completion target.
 )
-item(tt(/)var(pattern)tt(/-) [tt(%)var(lookahead)tt(%)] [tt(-)var(guard)] [tt(:)var(action)])(
+item(tt(/)var(pattern)tt(/-) [tt(%)var(lookahead)tt(%)] [tt(-)var(guard)] [tt(:)var(tag)tt(:)var(descr)tt(:)var(action)])(
 This is similar to `tt(/)var(pattern)tt(/) ...' but the var(action)s of the
 current and previous states are ignored even if the following state's
 `var(pattern)' matches the empty string.
Index: Src/Modules/zutil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zutil.c,v
retrieving revision 1.1.1.19
diff -u -r1.1.1.19 zutil.c
--- Src/Modules/zutil.c	2000/03/23 04:19:46	1.1.1.19
+++ Src/Modules/zutil.c	2000/05/04 20:03:12
@@ -1008,14 +1008,13 @@
     setiparam(var1, point1);
     setiparam(var2, point2);
 
-    if (!*subj) {
-	if (sm->nullacts)
-	    for (ln = firstnode(sm->nullacts); ln; ln = nextnode(ln)) {
-	        char *action = getdata(ln);
+    if (!comp && !*subj && sm->nullacts) {
+	for (ln = firstnode(sm->nullacts); ln; ln = nextnode(ln)) {
+	    char *action = getdata(ln);
 
-		if (action)
-		    execstring(action, 1, 0);
-	    }
+	    if (action)
+		execstring(action, 1, 0);
+	}
 	return 0;
     }
 
@@ -1036,7 +1035,7 @@
 	    if (next->pattern && !next->patprog) {
 	        tokenize(next->pattern);
 		if (!(next->patprog = patcompile(next->pattern, 0, NULL)))
-		    return 2;
+		    return 3;
 	    }
 	    if (next->pattern && pattry(next->patprog, subj) &&
 		(!next->guard || (execstring(next->guard, 1, 0), !lastval))) {
@@ -1102,7 +1101,7 @@
 }
 
 /*
-  usage: zregexparse string regex...
+  usage: zregexparse [-c] var1 var2 string regex...
   status:
     0: matched
     1: unmatched (all next state candidates are failed)
-- 
Tanaka Akira

Re: PATCH: Re: sudo completion problem

[Tanaka Akira]

In article <hvobt2moz0v.fsf@serein.m17n.org>,
  Tanaka Akira <akr@m17n.org> writes:

> +	: "$_ra_actions[@]"

Oops.  Debugging code is remained.

Index: Completion/Base/_regex_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/_regex_arguments,v
retrieving revision 1.2
diff -u -r1.2 _regex_arguments
--- Completion/Base/_regex_arguments	2000/05/04 20:16:09	1.2
+++ Completion/Base/_regex_arguments	2000/05/04 20:38:50
@@ -22,7 +22,7 @@
 # pattern = "/" ( glob | "[]" ) "/" [ "+" | "-" ]
 # lookahead = "%" glob "%"
 # guard = "-" zsh-code-to-eval
-# caction = ":" zsh-code-to-eval
+# caction = ":" tag ":" descr ":" zsh-code-to-eval
 # action = "{" zsh-code-to-eval "}"
 
 ## regex word sequence definition:
@@ -81,7 +81,6 @@
 	_ra_left="$_ra_line[_ra_p1 + 1, _ra_p2]"
 	_ra_right="$_ra_line[_ra_p2 + 1, -1]"
 	compset -p $(( $#PREFIX - $#_ra_line + $_ra_p1 ))
-	: "$_ra_actions[@]"
 	tmp=("${(@)_ra_actions%%:*}")
 	if (( $#tmp )); then
 	  _tags "$tmp[@]"
-- 
Tanaka Akira

Re: PATCH: Re: sudo completion problem

[Sven Wischnowsky]

Zefram wrote:

> Andrej Borsenkow wrote:
> >I think, it was the result of change for find (do not have article
> >handy) - in ``find /tmp -user'' -user was not recognised as option
> >because /tmp already was argument. So, this change made options be found
> >everywhere, even after arguments :-)
> 
> That's the wrong way to do it.  In the find command line, `-user' is not
> an option, it's an expression (or part thereof).  The expression starts
> with the first argument that starts with `-' and continues to the end
> of the line; the directory arguments must appear before the expression.
> Actual options are handled as dummy predicates, which is confusing to
> the user, but from our point of view means that they must be treated as
> part of the expression.
> 
> find has a unique syntax, with no options having the usual option syntax.
> Therefore it shouldn't be handled by the standard option completion
> function; it needs a dedicated find-expression completion function.

I don't think we really need this. Especially since it works quite
well for most cases where one would want to complete. We could change
_find to complete normal arguments with a `->foo' action and there
decide if directories or only \!, \( and \) should be completed
(depending on there being an `opion' on the line or not). In that case 
it should do the right thing in every case even if the -* things
aren't really options.

> The standard option completion function should, as is standard syntax,
> process options only before the first non-option argument.

It's a simple `(-)' for the first argument and allows us to use
_arguments both for things like _find *and* for commands with options
after sub-commands (cvs, etc.) and with commands whose command lines
can consist of multiple option/argument pairs (like zrecompile or some 
such). This flexibility is certainly a big win, as I hope you'll agree.


Andrej Borsenkow wrote:

> ...
> 
> This may be useful in other cases as well. cvs comes in mind
> immediately - common options, then checkout, update, etc as argument -
> and possibly (sub-)options and (sub-)arguments for every of them.

Sub-commands (and their options and arguments!) as arguments to
every(!) common option?

What's wrong with the way _cvs works now?

> I understand, that this is hierarchical structure that probably cannot
> be handled with one single table ... but, just as idea, imagine that
> action for `update' argument simply points to subarguments description
> ... or something like this ... this may be more readable than shell
> functions. May be not. But it is easier in cases, where we need several
> versions for different plattforms.

For the different-platform problem: the easiest and most readable way
is still and will ever be: a `case ... in ... esac'. Either setting up 
an array of _arguments-specifications or calling _arguments directly.

> Then I realised, that reverse situation exists with options - there is
> no way to describe options without - prefix. Consider dd or tar ("tar"
> not "GNU tar" :-), BSD ps ... In case of dd we have only options; in
> case of tar ot ps, the first word consists of single letter options with
> possible arguments in next words in order. There is no way to describe
> both case with _arguments (unless I'm mistaken).

I *really* don't think we should make _arguments do this. I know
_arguments is handy in many cases but it should *not* be the only
function used if that requires to make it more complicated than
compctl ever was.

The main reason for inventing the new completion system was to get at
the flexibility of shell functions, after all. If we want to give help 
completing certain kinds of things we should write new utility
functions that can be combined with existing functions or we should
write wrappers around existing functions (like _argument_sets). But we 
shouldn't put everything into one basket.

> And I'd like repeat once more - currently, when _arguments is using
> lexical structure to describe semantic, it is hard to add something. If
> we had flags ... (not suggesting breaking compatibility - but just for
> future use).

I don't know what you are alluding to here. When did you complain
about it? And to make me believe that flags would help here I need 1)
a more complete description of how the flags work and 2) examples
where currently `it is hard to add something'.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

PATCH: Re: sudo completion problem

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> bor@itsrm2% sudo rm -r
> Completing Kerberos realm
> Completing `Kerberos realm'
> 
> Hmm ... it treats -r as sudo option ... but, I think, it did work once
> ...

If it did, then only before we used the separate description to get
only external command names or because there was some other bug.

Hm. From the logic of the specifications used by _sudo, this
completion is correct, after all, there may be options between
arguments unless otherwise specified.

So this adds the special string `-' for exclusion lists which makes
the description for the options not be used any more. And it makes
this be used in the places where we have such _command_names/_normal
combinations.


Bye
 Sven

Index: Completion/User/_fakeroot
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_fakeroot,v
retrieving revision 1.1
diff -u -r1.1 _fakeroot
--- Completion/User/_fakeroot	2000/04/08 21:06:48	1.1
+++ Completion/User/_fakeroot	2000/05/03 14:39:09
@@ -2,5 +2,6 @@
 
 _arguments \
        '--lib[alternate wrapper library]:wrapper library:_files' \
-       '--faked[alternate faked binary]:fake binary:_command_names' \
+       '--faked[alternate faked binary]:fake binary: _command_names -e' \
+       '(-):command name: _command_names -e'  \
        '*::arguments: _normal'
Index: Completion/User/_rlogin
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_rlogin,v
retrieving revision 1.3
diff -u -r1.3 _rlogin
--- Completion/User/_rlogin	2000/04/11 07:57:57	1.3
+++ Completion/User/_rlogin	2000/05/03 14:39:09
@@ -17,7 +17,7 @@
       '-n[ignore stdin]' \
       '-l[specify login user name]:login as:_rlogin_users' \
       ':remote host name:_rlogin_hosts' \
-      ':command: _command_names -e' \
+      '(-):command: _command_names -e' \
       '*::command:->command' && ret=0
 
     if [[ -n "$state" ]]; then
Index: Completion/User/_ssh
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_ssh,v
retrieving revision 1.2
diff -u -r1.2 _ssh
--- Completion/User/_ssh	2000/04/05 11:28:09	1.2
+++ Completion/User/_ssh	2000/05/03 14:39:09
@@ -18,7 +18,7 @@
   ssh|slogin)
     args=(
       ':remote host name:->userhost'
-      ':command: _command_names -e'
+      '(-):command: _command_names -e'
       '*::args:->command'
     )
     ;&
Index: Completion/User/_sudo
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_sudo,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 _sudo
--- Completion/User/_sudo	2000/03/09 11:43:52	1.1.1.3
+++ Completion/User/_sudo	2000/05/03 14:39:09
@@ -15,5 +15,5 @@
        '-s[run SHELL]' \
        '-H[set HOME environment variable]' \
        '-S[read password from stdin]' \
-       ':complete command name: _command_names -e'  \
+       '(-):command name: _command_names -e'  \
        '*::arguments: _normal'
Index: Completion/User/_xargs
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_xargs,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 _xargs
--- Completion/User/_xargs	1999/09/07 12:55:12	1.1.1.2
+++ Completion/User/_xargs	2000/05/03 14:39:09
@@ -9,5 +9,5 @@
   '(-n -l)-L:number of input lines:' \
   '(-l -L)-n:maximum number of arguments:' \
   '-s:maximum command line length:' \
-  ':command: _command_names -e' \
-  '*::args:_normal'
+  '(-):command: _command_names -e' \
+  '*::args: _normal'
Index: Completion/X/_xutils
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/_xutils,v
retrieving revision 1.4
diff -u -r1.4 _xutils
--- Completion/X/_xutils	2000/04/11 07:57:57	1.4
+++ Completion/X/_xutils	2000/05/03 14:39:09
@@ -107,7 +107,8 @@
     '-screen:screen number:' \
     '-user:remote user name:_users' \
     ':remote host:_hosts' \
-    '*:command::command:_normal'
+    '(-):command: _command_names -e' \
+    '*:command: _normal'
   ;;
 xsetroot)
   _x_arguments \
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.31
diff -u -r1.31 compsys.yo
--- Doc/Zsh/compsys.yo	2000/05/03 08:46:52	1.31
+++ Doc/Zsh/compsys.yo	2000/05/03 14:39:11
@@ -2925,9 +2925,10 @@
 the argument described by the specification will not be offered if the
 option tt(-foo) is on the line. Also, the list may contain a single
 star as one of its elements to specify that the description for the
-rest arguments should not be used and it may contain a colon to
+rest arguments should not be used, a colon to
 specify that the descriptions for all normal (non-option-) arguments
-should not be used.
+should not be used and a hyphen to specify that the descriptions for
+all options should not be used.
 
 In each of the cases above, the var(action) says how the possible
 completions should be generated. In cases where only one of a fixed
Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.11
diff -u -r1.11 computil.c
--- Src/Zle/computil.c	2000/05/02 08:56:28	1.11
+++ Src/Zle/computil.c	2000/05/03 14:39:12
@@ -1040,7 +1040,12 @@
 	    }
 	    if (x[0] == ':' && !x[1])
 		d->argsactive = 0;
-	    else if (x[0] == '*' && !x[1]) {
+	    else if (x[0] == '-' && !x[1]) {
+		Caopt p;
+
+		for (p = d->opts; p; p = p->next)
+		    p->active = 0;
+	    } else if (x[0] == '*' && !x[1]) {
 		if (d->rest)
 		    d->rest->active = 0;
 	    } else if (x[0] >= '0' && x[0] <= '9') {

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: PATCH: Re: sudo completion problem

[Andrej Borsenkow]

>
> If it did, then only before we used the separate description to get
> only external command names or because there was some other bug.
>

I think, it was the result of change for find (do not have article
handy) - in ``find /tmp -user'' -user was not recognised as option
because /tmp already was argument. So, this change made options be found
everywhere, even after arguments :-) Just to make sure it won't break
this change ...

-andrej

Re: PATCH: Re: sudo completion problem

[Zefram]

Andrej Borsenkow wrote:
>I think, it was the result of change for find (do not have article
>handy) - in ``find /tmp -user'' -user was not recognised as option
>because /tmp already was argument. So, this change made options be found
>everywhere, even after arguments :-)

That's the wrong way to do it.  In the find command line, `-user' is not
an option, it's an expression (or part thereof).  The expression starts
with the first argument that starts with `-' and continues to the end
of the line; the directory arguments must appear before the expression.
Actual options are handled as dummy predicates, which is confusing to
the user, but from our point of view means that they must be treated as
part of the expression.

find has a unique syntax, with no options having the usual option syntax.
Therefore it shouldn't be handled by the standard option completion
function; it needs a dedicated find-expression completion function.
The standard option completion function should, as is standard syntax,
process options only before the first non-option argument.

No patch, sorry, I'm not up to speed on the completion functions yet.

-zefram

RE: PATCH: Re: sudo completion problem

[Andrej Borsenkow]

> Andrej Borsenkow wrote:
> >I think, it was the result of change for find (do not have article
> >handy) - in ``find /tmp -user'' -user was not recognised as option
> >because /tmp already was argument. So, this change made
> options be found
> >everywhere, even after arguments :-)
>
> That's the wrong way to do it.  In the find command line,
> `-user' is not
> an option, it's an expression (or part thereof).  The
> expression starts
> with the first argument that starts with `-' and continues to the end
> of the line; the directory arguments must appear before the
> expression.
> Actual options are handled as dummy predicates, which is confusing to
> the user, but from our point of view means that they must be
> treated as
> part of the expression.
>


I was about to suggest, that it still doable with _arguments - but then
realised, that there is no way to describe "structured arguments" or
"argument values". Every argument is treated as an independent word and
moreover, there is no way to "name" arguments at all.

So, the question is - how useful would it be to allow "named,
structured, ..." arguments? The point is, description vs. shell code.
Basically, be able to treat arguments in almost the same way as
options - with some separator in between. In this case, we could still
use _arguments for find - actually, it does it quite well currently, and
it is a pity to reinvent the wheel.

This may be useful in other cases as well. cvs comes in mind
immediately - common options, then checkout, update, etc as argument -
and possibly (sub-)options and (sub-)arguments for every of them.

I understand, that this is hierarchical structure that probably cannot
be handled with one single table ... but, just as idea, imagine that
action for `update' argument simply points to subarguments description
... or something like this ... this may be more readable than shell
functions. May be not. But it is easier in cases, where we need several
versions for different plattforms.

Then I realised, that reverse situation exists with options - there is
no way to describe options without - prefix. Consider dd or tar ("tar"
not "GNU tar" :-), BSD ps ... In case of dd we have only options; in
case of tar ot ps, the first word consists of single letter options with
possible arguments in next words in order. There is no way to describe
both case with _arguments (unless I'm mistaken).

And I'd like repeat once more - currently, when _arguments is using
lexical structure to describe semantic, it is hard to add something. If
we had flags ... (not suggesting breaking compatibility - but just for
future use).

-andrej

Re: PATCH: Re: sudo completion problem

[Tanaka Akira]

In article <000601bfb599$a9219f80$21c9ca95@mow.siemens.ru>,
  "Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru> writes:

> So, the question is - how useful would it be to allow "named,
> structured, ..." arguments? The point is, description vs. shell code.
> Basically, be able to treat arguments in almost the same way as
> options - with some separator in between. In this case, we could still
> use _arguments for find - actually, it does it quite well currently, and
> it is a pity to reinvent the wheel.

Although I think (-) is good extension, I agree that there are
commands which has too complex argument parsing routine to handle by
_arguments.  And it is true that writing dedicated handling routine as
shell function is too difficult in general.

We need intermediate solution for a completion function of such
commands: more powerful than _arguments and easier than shell
function.  But more difficult than _arguments, maybe.

My idea is already implemented: _regex_arguments.  Although currently
there are only three completion functions - _apt, _xwit and _xset -
which use _regex_arguments because it cannot use _arguments,  I think
there are more completion  functions which can be written bit more
simple if _regex_arguments is used.  Maybe, _xauth (and _cvs?).

> I understand, that this is hierarchical structure that probably cannot
> be handled with one single table ... but, just as idea, imagine that
> action for `update' argument simply points to subarguments description
> ... or something like this ... this may be more readable than shell
> functions. May be not. But it is easier in cases, where we need several
> versions for different plattforms.

In _regex_arguments, a arguments of commands are described as regex
like notation.  Of course, it can handle hierarchical one.

> Then I realised, that reverse situation exists with options - there is
> no way to describe options without - prefix. Consider dd or tar ("tar"
> not "GNU tar" :-), BSD ps ... In case of dd we have only options; in
> case of tar ot ps, the first word consists of single letter options with
> possible arguments in next words in order. There is no way to describe
> both case with _arguments (unless I'm mistaken).

_regex_arguments doesn't handle `-' or `+' specially.

> And I'd like repeat once more - currently, when _arguments is using
> lexical structure to describe semantic, it is hard to add something. If
> we had flags ... (not suggesting breaking compatibility - but just for
> future use).

_regex_arguments handle only parsing of arguments.  So other stuff
handled by _arguments such as descriptions, exclusive options must be
implemented by completion function writer.  It's bit hard task but we
can implement special feature easily.
-- 
Tanaka Akira

RE: PATCH: Re: sudo completion problem

[Andrej Borsenkow]

>
> Hm. From the logic of the specifications used by _sudo, this
> completion is correct, after all, there may be options between
> arguments unless otherwise specified.
>
> So this adds the special string `-' for exclusion lists which makes
> the description for the options not be used any more. And it makes
> this be used in the places where we have such _command_names/_normal
> combinations.
>


No, that is wrong approach. As Zefram pointed out, the logic is: first
argument terminates options. Anything after first argument must NOT be
trated as option. Cf.:

bor@itsrm2% diff  .zshrc --r
diff: Cannot access --r: No such file or directory

This applies to *all* arguments cases, not just a case with _normal.
Currently we get:

bor@itsrm2% gdiff --brief .zshrc -r<TAB>
bor@itsrm2% gdiff --brief .zshrc -r
Completing option
-B                        -- ignore lines that are all blank
-H                        -- assume large files and many small changes
-I                        -- ignore lines that match regex
.....

but in this case the ``--r'' is *argument* (== file) and not an option
any more:

bor@itsrm2% gdiff --brief .zshrc -r
gdiff: missing operand
gdiff: Try `gdiff --help' for more information.

The weird is, that *long* options (at least in this case) are
interpreted everywhere:

bor@itsrm2% gdiff --brief .zshrc --r
gdiff: option `--r' is ambiguous
gdiff: Try `gdiff --help' for more information.

In other words, what we need, is:

- short options must be treated consistent with Unix. First non-option
argument terminates short options. Because it is normal, default
behaviour - I suggest reverting change for find (to avoid modifying
*every* completion function) and

- for rare cases, when arguments and options (or what looks like
options - in case of find) can be intermixed - some way to express it is
needed. Option for _arguments may be?

- can somebody comment on long options case - is it expected behaviour?
Note, that I mean in this case "GNU long options". In this case, again,
_arguments should differentiate bewteen long and short case, again with
option. There are enough commands out there that use "long" options but
not GNU ones.

-andrej

Re: PATCH: Re: sudo completion problem

[Tanaka Akira]

In article <000501bfb728$30dd2f40$21c9ca95@mow.siemens.ru>,
  "Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru> writes:

> - can somebody comment on long options case - is it expected behaviour?
> Note, that I mean in this case "GNU long options". In this case, again,
> _arguments should differentiate bewteen long and short case, again with
> option. There are enough commands out there that use "long" options but
> not GNU ones.

It's not differences between long and short.  It's caused by the
difference between traditional getopt and GNU getopt.

By default, GNU getopt permutes argv and finds options on anywhere
(until `--').

If we can easily find out whether a command is linked with GNU getopt
or not, we can (and should) complete correctly.

But I think the current behavior is not bad because it completes all
correct (and some non-correct) candidates.  If _arguments behavior is
changed as you said, it completes only subset of correct candidates.
-- 
Tanaka Akira

RE: PATCH: Re: sudo completion problem

[Andrej Borsenkow]

>
> > - can somebody comment on long options case - is it
> expected behaviour?
> > Note, that I mean in this case "GNU long options". In this
> case, again,
> > _arguments should differentiate bewteen long and short
> case, again with
> > option. There are enough commands out there that use "long"
> options but
> > not GNU ones.
>
> It's not differences between long and short.  It's caused by the
> difference between traditional getopt and GNU getopt.
>

Yes, that is what I meant.

> By default, GNU getopt permutes argv and finds options on anywhere
> (until `--').
>
> If we can easily find out whether a command is linked with GNU getopt
> or not, we can (and should) complete correctly.
>

Well, hence I wrote "option for _arguments" for those commands, that use
GNU getopt.

> But I think the current behavior is not bad because it completes all
> correct (and some non-correct) candidates.  If _arguments behavior is
> changed as you said, it completes only subset of correct candidates.
>

No, it does not complete "corect" canditates. It completes totally wrong
set - options instead of arguments (files in case of diff). And this
change was introduced a couple of weeks ago ... and nobody has ever
complained before.

I think, old behaviour is "the least evil" case because it applies in
most cases. Apart from GNU getopt, there are commands that may intemix
options and arguments (with semantic - "this option applies to following
arguments" - do not have example ready) - but these are really special
cases and should be treated as such.

-andrej

Re: PATCH: Re: sudo completion problem

[Zefram]

Andrej Borsenkow wrote:
>The weird is, that *long* options (at least in this case) are
>interpreted everywhere:

Actually it's all options, it's the evil GNU getopt's default behaviour
(it can be turned off by putting a "+" at the start of the option string).

$ ls --version
ls (GNU fileutils) 4.0l
Written by Richard Stallman and David MacKenzie.

Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ls . -l
total 5
drwx------   17 zefram   fysh         1024 Mar 30 15:13 etc
drwxr-xr-x    5 zefram   fysh         1024 Mar  8 14:07 pub
drwxr-xr-x    6 zefram   fysh         1024 Apr  3 18:58 public_html
drwx------    3 zefram   fysh         1024 May  6 09:10 tmp
drwx------   11 zefram   fysh         1024 Mar  8 14:10 usr

If we can determine that a particular command is processing options in
this way, it would be nice to complet options accordingly.  However,
by default options should only be completed before the first non-option
argument.  In either case, options should never be completed after a "--".

I envision _arguments first of all deciding whether the command allows
options everywhere or not.  This should be under the control of the
caller, via options to _arguments; possible values are "everywhere",
"only before first argument", "autodetect GNU getopt" (if possible).
_arguments must also check for a "--" argument, and not do option
completion (regardless of option style) if the cursor is after the "--".
All of this then lets it decide whether to complete options or not;
non-option arguments are always a possibility, though we might want to
be clever about handling arguments that start with "-".

-zefram