Please add pinfo completion

Please add pinfo completion

[Vincent Lefevre]

"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)

Re: Please add pinfo completion

[Nikolai Weibull]

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

Re: Please add pinfo completion

[Mikael Magnusson]

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

Re: Please add pinfo completion

[Vincent Lefevre]

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)

Re: Please add pinfo completion

[Bart Schaefer]

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

Re: Please add pinfo completion

[Peter Stephenson]

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

Re: Please add pinfo completion

[Peter Stephenson]

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/

Re: Please add pinfo completion

[Vincent Lefevre]

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)

Re: Please add pinfo completion

[Andrey Borzenkov]

-----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-----

Re: Please add pinfo completion

[Andrey Borzenkov]

-----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-----

Re: Please add pinfo completion

[Andrey Borzenkov]

-----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-----

Re: Please add pinfo completion

[Peter Stephenson]

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