Assorted _arguments arguments

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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