* Please add pinfo completion @ 2006-10-07 1:35 Vincent Lefevre 2006-10-07 15:27 ` Nikolai Weibull 2006-10-08 21:13 ` Mikael Magnusson 0 siblings, 2 replies; 12+ messages in thread From: Vincent Lefevre @ 2006-10-07 1:35 UTC (permalink / raw) To: zsh-workers "pinfo" is an alternative info viewer. Normal arguments should be the same as those accepted by "info". Options are given by "pinfo --help". -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-07 1:35 Please add pinfo completion Vincent Lefevre @ 2006-10-07 15:27 ` Nikolai Weibull 2006-10-08 21:13 ` Mikael Magnusson 1 sibling, 0 replies; 12+ messages in thread From: Nikolai Weibull @ 2006-10-07 15:27 UTC (permalink / raw) To: zsh-workers On 10/7/06, Vincent Lefevre <vincent@vinc17.org> wrote: > "pinfo" is an alternative info viewer. Normal arguments should be the > same as those accepted by "info". Options are given by "pinfo --help". If you want something done, do it yourself. That's basically the mantra for completion definitions as well as many other things; especially when they are free/open-software things. People tend to define completions for commands they use themselves, and as you use pinfo, you're in a perfect position to write one. And remember, you'll (hopefully) be mentioned in the ChangeLog for all eternity for your contribution. nikolai ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-07 1:35 Please add pinfo completion Vincent Lefevre 2006-10-07 15:27 ` Nikolai Weibull @ 2006-10-08 21:13 ` Mikael Magnusson 2006-10-10 14:22 ` Vincent Lefevre 1 sibling, 1 reply; 12+ messages in thread From: Mikael Magnusson @ 2006-10-08 21:13 UTC (permalink / raw) To: zsh-workers On 10/7/06, Vincent Lefevre <vincent@vinc17.org> wrote: > "pinfo" is an alternative info viewer. Normal arguments should be the > same as those accepted by "info". Options are given by "pinfo --help". compdef _gnu_generic pinfo -- Mikael Magnusson ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-08 21:13 ` Mikael Magnusson @ 2006-10-10 14:22 ` Vincent Lefevre 2006-10-10 15:29 ` Bart Schaefer 2006-10-10 17:59 ` Peter Stephenson 0 siblings, 2 replies; 12+ messages in thread From: Vincent Lefevre @ 2006-10-10 14:22 UTC (permalink / raw) To: zsh-workers On 2006-10-08 23:13:49 +0200, Mikael Magnusson wrote: > On 10/7/06, Vincent Lefevre <vincent@vinc17.org> wrote: > >"pinfo" is an alternative info viewer. Normal arguments should be the > >same as those accepted by "info". Options are given by "pinfo --help". > > compdef _gnu_generic pinfo One problem is that it doesn't give help text. So, is there a way to generate a completion file (to be completed), assuming that the command has the --help feature? -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-10 14:22 ` Vincent Lefevre @ 2006-10-10 15:29 ` Bart Schaefer 2006-10-11 1:03 ` Vincent Lefevre 2006-10-10 17:59 ` Peter Stephenson 1 sibling, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2006-10-10 15:29 UTC (permalink / raw) To: Vincent Lefevre, zsh-workers On Oct 10, 4:22pm, Vincent Lefevre wrote: } } > compdef _gnu_generic pinfo } } One problem is that it doesn't give help text. So, is there a way } to generate a completion file (to be completed), assuming that the } command has the --help feature? If pinfo really is a drop-in replacement for info, you can just do: compdef pinfo=info ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-10 15:29 ` Bart Schaefer @ 2006-10-11 1:03 ` Vincent Lefevre 0 siblings, 0 replies; 12+ messages in thread From: Vincent Lefevre @ 2006-10-11 1:03 UTC (permalink / raw) To: zsh-workers On 2006-10-10 08:29:48 -0700, Bart Schaefer wrote: > If pinfo really is a drop-in replacement for info, you can just do: > > compdef pinfo=info Options are different. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-10 14:22 ` Vincent Lefevre 2006-10-10 15:29 ` Bart Schaefer @ 2006-10-10 17:59 ` Peter Stephenson 2006-10-10 21:23 ` Peter Stephenson ` (2 more replies) 1 sibling, 3 replies; 12+ messages in thread From: Peter Stephenson @ 2006-10-10 17:59 UTC (permalink / raw) To: zsh-workers Vincent Lefevre <vincent@vinc17.org> wrote: > > compdef _gnu_generic pinfo > > One problem is that it doesn't give help text. So, is there a way > to generate a completion file (to be completed), assuming that the > command has the --help feature? OK, here is _arguments updated to provide option descriptions from --help text automatically. It'll be a little slower since a horrible nested parameter substitution has turned into a loop. (I didn't even try to understand it in too much depth, I just started again from scratch.) However, there is in any case a cache, and there was an external program to run at that point anyway, so I don't think it'll make much difference. In my case when using _gnu_generic for pinfo completion (with some non-standard configuration settings; you're unlikely to get exactly the same), "pinfo --^D" gives me Completing option --apropos # call apropos if nothing found --clear-at-exit # clear screen at exit --cut-man-headers # cut out repeated man headers --dont-handle-without-tag-table # don't display texinfo pages without tag --file # synonym for -r --force-manual-tag-table # force manual detection of tag table --help # help --long-manual-links # use long link names in manuals --manual # use man page --node # jump directly to the node nodename --plain-apropos # call only apropos --raw-filename # use raw filename --rcfile # use alternate rcfile --squeeze-manlines # cut empty lines from manual pages --version # version which certainly impressed me, I can tell you. After fiddling with _arguments for an hour, I'd like to say "if there's a problem, DEAL WITH IT", but since I'm now a professional software engineer, I'll have a go at fixing any problems I've created with this change; there are bound to be some. Note in particular I found some problems with optional arguments like "--option[=STUFF]" and tried to address them, but this isn't properly tested. It looked like somebody had fixed previous problems just by treating them as mandatory arguments, but the code should have handled them better than that. I have to admit this was at least more tractable than the other problem I've been tackling today. Index: Completion/Base/Utility/_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v retrieving revision 1.17 diff -u -r1.17 _arguments --- Completion/Base/Utility/_arguments 27 Sep 2006 16:53:59 -0000 1.17 +++ Completion/Base/Utility/_arguments 10 Oct 2006 17:52:22 -0000 @@ -6,6 +6,7 @@ local long cmd="$words[1]" descr mesg subopts opt usecc autod local oldcontext="$curcontext" hasopts rawret optarg singopt alwopt local setnormarg +local -a match mbegin mend long=$argv[(I)--] if (( long )); then @@ -68,32 +69,59 @@ # those hyphens and anything from the space or tab after the # option up to the end. - lopts=("--${(@)${(@)^${(@)${(@)${(@M)${(@ps:\n:j:\n:)${(@)${(@M)${(@f)$(_call_program options ${~words[1]} --help 2>&1)//\[--/ ---}:#[ ]#-*}//,/ -}}:#[ ]#--*}#*--}%%[] ]*}:#}//\[=/=}") + _call_program options ${~words[1]} --help 2>&1 | while read opt; do + tmp=() + while [[ $opt = [,[:space:]]#(#b)(-[^,[:space:]]#)(*) ]]; do + # We used to remove the brackets from "[=STUFF]", + # but later the code appears to handle it with the brackets + # present. Maybe the problem was that the intervening code + # didn't. If it's buggy without removing them, the problem + # probably is later, not here. + if [[ -z ${tmp[(r)${match[1]%%[^a-zA-Z0-9-]#}]} ]]; then + tmp+=($match[1]) + fi + opt=$match[2] + done + # If there's left over text, assume it's a description; it + # may be truncated but if it's too long it's no use anyway. + # There's one hiccup: we sometimes get descriptions like + # --foo fooarg Do some foo stuff with foo arg + # and we need to remove fooarg. Use whitespace for hints. + opt=${opt## [^[:space:]]## } + opt=${opt##[[:space:]]##} + # Add description after a ":", converting any : in the description + # to a -. Use RCQUOTES to append this to all versions of the option. + lopts+=("${^tmp[@]}"${opt:+:${opt//:/-}}) + done # Remove options also described by user-defined specs. tmp=() - for opt in "${(@)${(@)lopts:#--}%%\=*}"; do + # Ignore any argument and description information when searching + # the long options array here and below. + for opt in "${(@)${(@)lopts:#--}%%[\[:=]*}"; do # Using (( ... )) gives a parse error. let "$tmpargv[(I)(|\([^\)]#\))(|\*)${opt}(|[-+]|=(|-))(|\[*\])(|:*)]" || - tmp=( "$tmp[@]" "$lopts[(r)$opt(|=*)]" ) + tmp=( "$tmp[@]" "$lopts[(r)$opt(|[\[:=]*)]" ) done lopts=( "$tmp[@]" ) # Now remove all ignored options ... while (( $#iopts )); do - lopts=( ${lopts:#$~iopts[1]} ) + lopts=( ${lopts:#$~iopts[1](|[\[:=]*)} ) shift iopts done # ... and add "same" options while (( $#sopts )); do + # This implements adding things like --disable-* based + # on the existence of --enable-*. + # TODO: there's no anchoring here, is that correct? + # If it's not, careful with the [\[:=]* stuff. lopts=( $lopts ${lopts/$~sopts[1]/$sopts[2]} ) shift 2 sopts done @@ -110,9 +138,15 @@ # First, we get the pattern and the action to use and take them # from the positional parameters. + # This is the first bit of the arguments in the special form + # for converting --help texts, taking account of any quoting + # of colons. pattern="${${${(M)1#*[^\\]:}[1,-2]}//\\\\:/:}" + # Any action specifications that go with it. descr="${1#${pattern}}" if [[ "$pattern" = *\(-\) ]]; then + # This is the special form to disallow arguments + # in the next word. pattern="$pattern[1,-4]" dir=- else @@ -124,8 +158,10 @@ # list we have built. If no option matches the pattern, we # continue with the next. - tmp=("${(@M)lopts:##$~pattern}") - lopts=("${(@)lopts:##$~pattern}") + # Ignore :descriptions at the ends of lopts for matching this; + # they aren't in the patterns. + tmp=("${(@M)lopts:##$~pattern(|:*)}") + lopts=("${(@)lopts:##$~pattern(|:*)}") (( $#tmp )) || continue @@ -140,11 +176,28 @@ if [[ "$descr" = :\=* ]]; then for opt in "$tmpo[@]"; do - cache=( "$cache[@]" - "${${opt%%\=*}//[^a-zA-Z0-9-]}=::${(L)${opt%\]}#*\=}: " ) + # Look for --option:description and turn it into + # --option[description]. We didn't do that above + # since it could get confused with the [=ARG] stuff. + if [[ $opt = (#b)(*):([^:]#) ]]; then + opt=$match[1] + descr="[${match[2]}]" + else + descr= + fi + cache=( + "$cache[@]" + "${${opt%%\=*}//[^a-zA-Z0-9-]}=${descr}::${(L)${opt%\]}#*\=}: " + ) done else - tmpo=("${(@)${(@)tmpo%%\=*}//[^a-zA-Z0-9-]}") + # We don't handle the [description] form here. + # TODO: we could with a bit of rewriting. + # + # The "[" didn't get removed here until I added it. + # This may be why we used to try to remove the square brackets + # higher up. + tmpo=("${(@)${(@)tmpo%%\[\=*}//[^a-zA-Z0-9-]}") if [[ "$descr" = ::* ]]; then cache=( "$cache[@]" "${(@)^tmpo}=${dir}${descr}" ) else @@ -154,6 +207,8 @@ fi # Descriptions with `=': mandatory argument. + # Basically the same as the foregoing. + # TODO: could they be combined? tmpo=("${(@M)tmp:#*\=*}") if (( $#tmpo )); then @@ -161,8 +216,16 @@ if [[ "$descr" = :\=* ]]; then for opt in "$tmpo[@]"; do - cache=( "$cache[@]" - "${${opt%%\=*}//[^a-zA-Z0-9-]}=:${(L)${opt%\]}#*\=}: " ) + if [[ $opt = (#b)(*):([^:]#) ]]; then + opt=$match[1] + descr="[${match[2]}]" + else + descr= + fi + cache=( + "$cache[@]" + "${${opt%%\=*}//[^a-zA-Z0-9-]}=${descr}:${(L)${opt%\]}#*\=}: " + ) done else tmpo=("${(@)${(@)tmpo%%\=*}//[^a-z0-9-]}") @@ -175,7 +238,15 @@ # as described by $descr. if (( $#tmp )); then - tmp=("${(@)tmp//[^a-zA-Z0-9-]}") + tmp=( + # commands with a description of the option (as opposed + # to the argument, which is what descr contains): needs to be + # "option[description]". + # Careful: \[ on RHS of substitution keeps the backslash, + # I discovered after about half an hour, so don't do that. + "${(@)^${(@)tmp:#^*:*}//:/[}]" + # commands with no description + "${(@)${(@)tmp:#*:*}//[^a-zA-Z0-9-]}") if [[ -n "$descr" && "$descr" != ': : ' ]]; then cache=( "$cache[@]" "${(@)^tmp}${descr}" ) else -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-10 17:59 ` Peter Stephenson @ 2006-10-10 21:23 ` Peter Stephenson 2006-10-11 2:48 ` Andrey Borzenkov 2006-10-11 2:52 ` Andrey Borzenkov 2 siblings, 0 replies; 12+ messages in thread From: Peter Stephenson @ 2006-10-10 21:23 UTC (permalink / raw) To: Zsh Hackers' List On Tue, 10 Oct 2006 18:59:59 +0100 Peter Stephenson <pws@csr.com> wrote: > OK, here is _arguments updated to provide option descriptions from --help > text automatically. I tried this on zsh's own configure script. There was a bug: square brackets in the descriptions caused comparguments to barf. I've also added various improvements based on the handling of configure: - now --option[descriptions] are handled in all cases, even if a separate option argument description is provided - configure --help prints descriptions on the next line if the don't fit; I've taken account of this - I've also consistently used array+=() syntax in _arguments, which I have absolutely no intention of porting back to before 4.0. Every option for ./configure now has a comment in verbose mode (which you can, of course, turn off if you don't like it), as do all long options for GNU tar. However, if you don't WANT to be impressed you don't NEED to be. Index: Completion/Base/Utility/_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v retrieving revision 1.18 diff -u -r1.18 _arguments --- Completion/Base/Utility/_arguments 10 Oct 2006 18:06:28 -0000 1.18 +++ Completion/Base/Utility/_arguments 10 Oct 2006 21:18:24 -0000 @@ -3,7 +3,7 @@ # Complete the arguments of the current command according to the # descriptions given as arguments to this function. -local long cmd="$words[1]" descr mesg subopts opt usecc autod +local long cmd="$words[1]" descr odescr mesg subopts opt opt2 usecc autod local oldcontext="$curcontext" hasopts rawret optarg singopt alwopt local setnormarg local -a match mbegin mend @@ -51,9 +51,9 @@ tmp=( "${(@P)tmp}" ) fi if [[ "$1" = -i* ]]; then - iopts=( "$iopts[@]" "$tmp[@]" ) + iopts+=( "$tmp[@]" ) else - sopts=( "$sopts[@]" "$tmp[@]" ) + sopts+=( "$tmp[@]" ) fi shift cur done @@ -69,8 +69,28 @@ # those hyphens and anything from the space or tab after the # option up to the end. - _call_program options ${~words[1]} --help 2>&1 | while read opt; do - tmp=() + tmp=() + _call_program options ${~words[1]} --help 2>&1 | while IFS= read -r opt; do + if (( ${#tmp} )); then + # Previous line had no comment. Is the current one suitable? + # It's hard to be sure, but if it there was nothing on the + # previous line and the current one is indented more than + # a couple of spaces (and isn't completely whitespace or punctuation) + # there's a pretty good chance. + if [[ $opt = [[:space:]][[:space:]][[:space:]]*[[:alpha:]]* ]]; then + # Assume so. + opt=${opt##[[:space:]]##} + # Same substitution as below. + lopts+=("${^tmp[@]}":${${${opt//:/-}//\[/(}//\]/)}) + tmp=() + # Finished with this line. + continue + else + # Still no comment, add the previous options anyway. + lopts+=("${tmp[@]}") + tmp=() + fi + fi while [[ $opt = [,[:space:]]#(#b)(-[^,[:space:]]#)(*) ]]; do # We used to remove the brackets from "[=STUFF]", # but later the code appears to handle it with the brackets @@ -89,10 +109,19 @@ # and we need to remove fooarg. Use whitespace for hints. opt=${opt## [^[:space:]]## } opt=${opt##[[:space:]]##} - # Add description after a ":", converting any : in the description - # to a -. Use RCQUOTES to append this to all versions of the option. - lopts+=("${^tmp[@]}"${opt:+:${opt//:/-}}) + if [[ -n $opt ]]; then + # Add description after a ":", converting any : in the description + # to a -. Use RCQUOTES to append this to all versions of the option. + lopts+=("${^tmp[@]}":${${${opt//:/-}//\[/(}//\]/)}) + tmp=() + # If there's no comment, we'll see if there's one on the + # next line. + fi done + # Tidy up any remaining uncommented options. + if (( ${#tmp} )); then + lopts+=("${tmp[@]}") + fi # Remove options also described by user-defined specs. @@ -104,7 +133,7 @@ # Using (( ... )) gives a parse error. let "$tmpargv[(I)(|\([^\)]#\))(|\*)${opt}(|[-+]|=(|-))(|\[*\])(|:*)]" || - tmp=( "$tmp[@]" "$lopts[(r)$opt(|[\[:=]*)]" ) + tmp+=( "$lopts[(r)$opt(|[\[:=]*)]" ) done lopts=( "$tmp[@]" ) @@ -122,7 +151,7 @@ # on the existence of --enable-*. # TODO: there's no anchoring here, is that correct? # If it's not, careful with the [\[:=]* stuff. - lopts=( $lopts ${lopts/$~sopts[1]/$sopts[2]} ) + lopts+=( ${lopts/$~sopts[1]/$sopts[2]} ) shift 2 sopts done @@ -130,8 +159,12 @@ # The last one matches all options; the `special' description and action # makes those options be completed without an argument description. - set -- "$@" '*=FILE*:file:_files' \ - '*=(DIR|PATH)*:directory:_files -/' '*=*:=: ' '*: : ' + argv+=( + '*=FILE*:file:_files' + '*=(DIR|PATH)*:directory:_files -/' + '*=*:=: ' + '*: : ' + ) while (( $# )); do @@ -174,36 +207,25 @@ if (( $#tmpo )); then tmp=("${(@)tmp:#*\[\=*}") - if [[ "$descr" = :\=* ]]; then - for opt in "$tmpo[@]"; do - # Look for --option:description and turn it into - # --option[description]. We didn't do that above - # since it could get confused with the [=ARG] stuff. - if [[ $opt = (#b)(*):([^:]#) ]]; then - opt=$match[1] - descr="[${match[2]}]" - else - descr= - fi - cache=( - "$cache[@]" - "${${opt%%\=*}//[^a-zA-Z0-9-]}=${descr}::${(L)${opt%\]}#*\=}: " - ) - done - else - # We don't handle the [description] form here. - # TODO: we could with a bit of rewriting. - # - # The "[" didn't get removed here until I added it. - # This may be why we used to try to remove the square brackets - # higher up. - tmpo=("${(@)${(@)tmpo%%\[\=*}//[^a-zA-Z0-9-]}") - if [[ "$descr" = ::* ]]; then - cache=( "$cache[@]" "${(@)^tmpo}=${dir}${descr}" ) - else - cache=( "$cache[@]" "${(@)^tmpo}=${dir}:${descr}" ) - fi - fi + for opt in "$tmpo[@]"; do + # Look for --option:description and turn it into + # --option[description]. We didn't do that above + # since it could get confused with the [=ARG] stuff. + if [[ $opt = (#b)(*):([^:]#) ]]; then + opt=$match[1] + odescr="[${match[2]}]" + else + odescr= + fi + opt2=${${opt%%\[\=*}//[^a-zA-Z0-9-]}=${dir}${odescr} + if [[ "$descr" = :\=* ]]; then + cache+=( "${opt2}::${(L)${opt%\]}#*\=}: " ) + elif [[ "$descr" = ::* ]]; then + cache+=( "${opt2}${descr}" ) + else + cache+=( "${opt2}:${descr}" ) + fi + done fi # Descriptions with `=': mandatory argument. @@ -214,24 +236,20 @@ if (( $#tmpo )); then tmp=("${(@)tmp:#*\=*}") - if [[ "$descr" = :\=* ]]; then - for opt in "$tmpo[@]"; do - if [[ $opt = (#b)(*):([^:]#) ]]; then - opt=$match[1] - descr="[${match[2]}]" - else - descr= - fi - cache=( - "$cache[@]" - "${${opt%%\=*}//[^a-zA-Z0-9-]}=${descr}:${(L)${opt%\]}#*\=}: " - ) - done - else - tmpo=("${(@)${(@)tmpo%%\=*}//[^a-z0-9-]}") - - cache=( "$cache[@]" "${(@)^tmpo}=${dir}${descr}" ) - fi + for opt in "$tmpo[@]"; do + if [[ $opt = (#b)(*):([^:]#) ]]; then + opt=$match[1] + odescr="[${match[2]}]" + else + odescr= + fi + opt2="${${opt%%\=*}//[^a-zA-Z0-9-]}=${dir}${odescr}" + if [[ "$descr" = :\=* ]]; then + cache+=( "${opt2}:${(L)${opt%\]}#*\=}: " ) + else + cache+=( "${opt2}${descr}" ) + fi + done fi # Everything else is just added as an option without arguments or @@ -248,9 +266,9 @@ # commands with no description "${(@)${(@)tmp:#*:*}//[^a-zA-Z0-9-]}") if [[ -n "$descr" && "$descr" != ': : ' ]]; then - cache=( "$cache[@]" "${(@)^tmp}${descr}" ) + cache+=( "${(@)^tmp}${descr}" ) else - cache=( "$cache[@]" "$tmp[@]" ) + cache+=( "$tmp[@]" ) fi fi done @@ -344,11 +362,11 @@ action="${${action[3,-1]##[ ]#}%%[ ]#}" if (( ! $state[(I)$action] )); then comparguments -W line opt_args - state=( "$state[@]" "$action" ) + state+=( "$action" ) if [[ -n "$usecc" ]]; then curcontext="${oldcontext%:*}:$subc" else - context=( "$context[@]" "$subc" ) + context+=( "$subc" ) fi compstate[restore]='' aret=yes @@ -475,7 +493,7 @@ fi single=yes else - next=( "$next[@]" "$odirect[@]" ) + next+=( "$odirect[@]" ) _describe -O option \ next -Q -M "$matcher" -- \ direct -QS '' -M "$matcher" -- \ -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-10 17:59 ` Peter Stephenson 2006-10-10 21:23 ` Peter Stephenson @ 2006-10-11 2:48 ` Andrey Borzenkov [not found] ` <200610110933.k9B9XJTB021853@news01.csr.com> 2006-10-11 2:52 ` Andrey Borzenkov 2 siblings, 1 reply; 12+ messages in thread From: Andrey Borzenkov @ 2006-10-11 2:48 UTC (permalink / raw) To: zsh-workers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 10 October 2006 21:59, Peter Stephenson wrote: > Vincent Lefevre <vincent@vinc17.org> wrote: > > > compdef _gnu_generic pinfo > > > > One problem is that it doesn't give help text. So, is there a way > > to generate a completion file (to be completed), assuming that the > > command has the --help feature? > > OK, here is _arguments updated to provide option descriptions from --help > text automatically. > I do not think it should be done unconditionally. I guess it has been discussed back when we started all this completion candy; and common opinion was that running arbitrary program with --help may have unwanted side effects. Also, making it explicit allows passing different sorts of --help; specifically I am thinking about KDE/Qt --help-qt, --help-kde, --help-all, etc. And finally it opens up a can of worms that is called l10n. Now-a-days you almost sure gets localized help output; so be prepared for questions "why this one appears in Russian and this one not" :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLFuNR6LMutpd94wRApjOAJ99LPWo7Yd1AQrNIdTFDeDFJerLDQCfSg8t LnpZd2zxNnDyG2NRZ3EcVIE= =QdNs -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <200610110933.k9B9XJTB021853@news01.csr.com>]
* Re: Please add pinfo completion [not found] ` <200610110933.k9B9XJTB021853@news01.csr.com> @ 2006-10-11 15:43 ` Andrey Borzenkov 2006-10-11 16:30 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Andrey Borzenkov @ 2006-10-11 15:43 UTC (permalink / raw) To: zsh-workers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Was it intentionally sent to me personally and not to list? On Wednesday 11 October 2006 13:33, you wrote: > Andrey Borzenkov wrote: > > On Tuesday 10 October 2006 21:59, Peter Stephenson wrote: > > > OK, here is _arguments updated to provide option descriptions from > > > --help text automatically. > > > > I do not think it should be done unconditionally. > > Do what unconditionally? > > Running --help has never been done unconditionally, I should not answer 5 minutes before going off to work :( > only under the > control of specific completions like _tar and _configure, or if > requested via _gnu_generic. That hasn't changed; I've only upgraded > the way it fetches descriptions. There is some minimal sanity checking > for some of these programmes and I would be happy to add more. > I misunderstood your patch. I assumed it was now calling 'command --help' for all _arguments invocations and was using its output in preference to descriptions given on command line. OK so we now have two possiblities - - nice localized output but without any possibility to give specific options' argument(s) completion - - unlimited freedom in completing options limited to hardcoded english descriptions. Now when you are probably the only person understanding how _argument works - any chances to merge the above? I.e. extra option to _arguments (something like _agruments -h help_option, where help_option is variable) to request description for options? This does not need all this hairy processing or recognizing of *=FILE or like - just fetch options with help text and use it instead of supplied one if found. This gives l10n for large part of commands for free. I leave the rest for list to see (I do not see any personal info here :) > For example, we could ensure that "configure" was run with an explicit > path such as ./configure or ../configure and if not refuse to run it > with --help; or we could refuse to do it as root without a further style > set by the user. > > The descriptions themselves have never been printed unconditionally, > only under the control of the verbose option. You can turn this off, > for example, for tar completion under all contextual completers with > > zstyle ':completion::*:tar:*' verbose false > > > And finally it opens up a can of worms that is called l10n. Now-a-days > > you almost sure gets localized help output; so be prepared for questions > > "why this one appears in Russian and this one not" :) > > This is surely a great deal easier for automatically generated > descriptions than otherwise; none of LC_* or LANG are reset in > _arguments. The only big issue I can see is with the additional logic > to match *=FILE* and *=(DIR|PATH)* patterns and turn them into the > appropriate sort of completion. > > A simple hash-bashed function system for localization of this sort of > thing wouldn't be too hard to implement; it's a much easier task than > doing the same for the main shell. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD4DBQFFLREuR6LMutpd94wRAmqdAKCKWQYADPnsnavZBb61MqHVOQOFdgCYuep5 jEddMDSQEpUYpCtDIoHc9g== =Aeh6 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-11 15:43 ` Andrey Borzenkov @ 2006-10-11 16:30 ` Peter Stephenson 0 siblings, 0 replies; 12+ messages in thread From: Peter Stephenson @ 2006-10-11 16:30 UTC (permalink / raw) To: zsh Andrey Borzenkov <arvidjaar@newmail.ru> wrote: > Was it intentionally sent to me personally and not to list? No, I've been doing that ever since the default changed about ten years ago. > OK so we now have two possiblities > > - - nice localized output but without any possibility to give specific > options' argument(s) completion > > - - unlimited freedom in completing options limited to hardcoded english > descriptions. > > Now when you are probably the only person understanding how _argument > works - > any chances to merge the above? I.e. extra option to _arguments (something > like _agruments -h help_option, where help_option is variable) to request > description for options? This does not need all this hairy processing or > recognizing of *=FILE or like - just fetch options with help text and use it > instead of supplied one if found. This gives l10n for large part of commands > for free. This requires two bits, a system of supplying descriptions indicating the text is localizable and providing an index and a system for storing and retrieving those localized descriptions. I think this needs to be done as low as possible in the completion system so that as many features as possible, not just _arguments, can benefit. This means wherever the explanation string to be passed to compadd is modified. In particular _describe has a lot to do with it, though how much I don't know; it's probably the place to start. Probably the first thing to do, however, would be to add a localization function system under Functions to retrieve data based on keywords. It can then be inserted gradually into the completion system at any appropriate level. We need to decide: - Where to store data. The path should be configurable from the shell. Files will presumably correspond to languages and I guess the usual system of ru, ru_RU, ru_RU.UTF-8 etc. will work, though I don't know the details of how it's searched. Someone may be able to provide a suitable algorithm for turning LC_ALL/LC_MESSAGE/LANG into a directory name. We'd want to be able to configure the top of the path before locale-specific bit so that we can use the information in the source tree rather than installation, for example. They'd be in the same format and just installed by tarring the directories, though we'd probably want to do it module by module in the same way Functions currently is in config.modules. - What format the data is in. This should make access from shell code easy. The simplest possibility is a file containing definitions of associative arrays, where the keys are as discussed below. Then it's simply a question of sourcing the file. However, that could produce huge memory usage so we may want to be cleverer. We could add additional paths to get to the file, for example. - How to access the data. This is simpler. It's probably going to be a function that sets REPLY. It can do the locale investigation itself, although we may want to cache the result, e.g. if the locale is ru_RU.UTF-8 work out a path to the top of the file tree once and keep it until the locale changes. - The syntax for keys. If we're clever we can use this to simplify the data access problem. For example, a format like "<L10N%comp/cmd/mount%mount-point>" gives - a reasonably specific format that isn't going to be confused with other descriptions. I deliberately avoided colons because they're already overloaded in the completion system. - the path to a file <top-of-stuff-for-current-locale>/comp/cmd/mount.zmsg that could be sourced to give local completions - the name of a key mount-point for the hash in that file that contains the appropriate string to be retrieved. This can probably be retrieved to ensure the maximum re-use, e.g. we keep the same hash in memory while the path after the first % doesn't change and return the requested element. This would work neatly in a case like this where the localization file is associated with the particular contextual completion. Further discussion is invited. -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Please add pinfo completion 2006-10-10 17:59 ` Peter Stephenson 2006-10-10 21:23 ` Peter Stephenson 2006-10-11 2:48 ` Andrey Borzenkov @ 2006-10-11 2:52 ` Andrey Borzenkov 2 siblings, 0 replies; 12+ messages in thread From: Andrey Borzenkov @ 2006-10-11 2:52 UTC (permalink / raw) To: zsh-workers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 10 October 2006 21:59, Peter Stephenson wrote: > --file # synonym for -r does it also do merging of options with similar descriptions? It probably should (I believe it is done internally in compdescribe) but will _arguments extract several options on a line, like '--file -r ....'? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLFx9R6LMutpd94wRAnBgAKCM5NRyLEVHEnOA+XrxNcxK6hkPGgCgqUOi jXWalB4cWMOwHGGLGfVqGDg= =jvHK -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-10-11 16:53 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-10-07 1:35 Please add pinfo completion Vincent Lefevre 2006-10-07 15:27 ` Nikolai Weibull 2006-10-08 21:13 ` Mikael Magnusson 2006-10-10 14:22 ` Vincent Lefevre 2006-10-10 15:29 ` Bart Schaefer 2006-10-11 1:03 ` Vincent Lefevre 2006-10-10 17:59 ` Peter Stephenson 2006-10-10 21:23 ` Peter Stephenson 2006-10-11 2:48 ` Andrey Borzenkov [not found] ` <200610110933.k9B9XJTB021853@news01.csr.com> 2006-10-11 15:43 ` Andrey Borzenkov 2006-10-11 16:30 ` Peter Stephenson 2006-10-11 2:52 ` Andrey Borzenkov
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).