* Re: PATCH: Re: sudo completion problem @ 2000-05-08 9:00 Sven Wischnowsky 2000-05-08 9:44 ` optional argument? Sven Wischnowsky 2000-05-08 15:25 ` PATCH: Re: sudo completion problem Tanaka Akira 0 siblings, 2 replies; 7+ messages in thread From: Sven Wischnowsky @ 2000-05-08 9:00 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: optional argument? @ 2000-05-08 9:44 ` Sven Wischnowsky 2000-05-08 10:01 ` Peter Stephenson 2000-05-08 14:49 ` Tanaka Akira 0 siblings, 2 replies; 7+ messages in thread From: Sven Wischnowsky @ 2000-05-08 9:44 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: optional argument? 2000-05-08 9:44 ` optional argument? Sven Wischnowsky @ 2000-05-08 10:01 ` Peter Stephenson 2000-05-08 14:49 ` Tanaka Akira 1 sibling, 0 replies; 7+ messages in thread From: Peter Stephenson @ 2000-05-08 10:01 UTC (permalink / raw) To: Zsh hackers list > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: optional argument? 2000-05-08 9:44 ` optional argument? Sven Wischnowsky 2000-05-08 10:01 ` Peter Stephenson @ 2000-05-08 14:49 ` Tanaka Akira 2000-05-08 17:58 ` Assorted _arguments arguments Bart Schaefer 1 sibling, 1 reply; 7+ messages in thread From: Tanaka Akira @ 2000-05-08 14:49 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Assorted _arguments arguments 2000-05-08 14:49 ` Tanaka Akira @ 2000-05-08 17:58 ` Bart Schaefer 2000-05-08 18:12 ` Peter Stephenson 0 siblings, 1 reply; 7+ messages in thread From: Bart Schaefer @ 2000-05-08 17:58 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Assorted _arguments arguments 2000-05-08 17:58 ` Assorted _arguments arguments Bart Schaefer @ 2000-05-08 18:12 ` Peter Stephenson 0 siblings, 0 replies; 7+ messages in thread From: Peter Stephenson @ 2000-05-08 18:12 UTC (permalink / raw) To: Zsh hackers list 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PATCH: Re: sudo completion problem 2000-05-08 9:00 PATCH: Re: sudo completion problem Sven Wischnowsky 2000-05-08 9:44 ` optional argument? Sven Wischnowsky @ 2000-05-08 15:25 ` Tanaka Akira 1 sibling, 0 replies; 7+ messages in thread From: Tanaka Akira @ 2000-05-08 15:25 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-05-08 18:13 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-05-08 9:00 PATCH: Re: sudo completion problem Sven Wischnowsky 2000-05-08 9:44 ` optional argument? Sven Wischnowsky 2000-05-08 10:01 ` Peter Stephenson 2000-05-08 14:49 ` Tanaka Akira 2000-05-08 17:58 ` Assorted _arguments arguments Bart Schaefer 2000-05-08 18:12 ` Peter Stephenson 2000-05-08 15:25 ` PATCH: Re: sudo completion problem Tanaka Akira
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).