_arguments parsing of --help output

_arguments parsing of --help output

[Bart Schaefer]

Many GNU commands include short options in the --help output as well as long
ones; e.g. `tar --help' emits lines like "-m, --modifcation-time ...".  The
code in _arguments accounts for this by splitting the line at commas, but
then discards the short form of the option.

Is there a reason that we don't attempt to complete the short forms as well?

I'm also curious in what circumstances the code to "... split the result
again at newlines after joining the old array elements with newlines
between them" ever makes a difference?  It strikes me as redundant.

More succinctly, what's wrong with the following reformulation of the
lopts assignment at lines 70-72 of _arguments?

    lopts=("-${(@)^${(@)${(@)${(@M)${(@)${(@M)${(@f)$(_call options ${~words[1]} --help 2>&1)//\[--/
--}:#[ 	]#-*}//,/
}:#[ 	]#-*}#*-}%%[]	 ]*}:#}")

Re: _arguments parsing of --help output

[Bart Schaefer]

On Jul 21,  3:22pm, Bart Schaefer wrote:
> 
> I'm also curious in what circumstances the code to "... split the result
> again at newlines after joining the old array elements with newlines
> between them" ever makes a difference?  It strikes me as redundant.

To answer myself ... it eliminates empty array elements, which probably
don't matter because they won't match the `-' prefix and so compadd will
discard them; but it's probably cleaner to explicitly squelch them.

Re: _arguments parsing of --help output

[Sven Wischnowsky]

Bart Schaefer wrote:

> Many GNU commands include short options in the --help output as well as long
> ones; e.g. `tar --help' emits lines like "-m, --modifcation-time ...".  The
> code in _arguments accounts for this by splitting the line at commas, but
> then discards the short form of the option.
> 
> Is there a reason that we don't attempt to complete the short forms as well?

The only problem I can see is if the user-supplied specs contain those 
options, too. Currently _arguments does not discard additional
definitions but the first one takes precedence with respect to
argument handling (arguments of options):

  _arguments '-e:ea:(1 2)' -e -b -p

This will make `foo -e <TAB>' complete `1' and `2' but `foo -' lists
both (with auto-descriptions).

Hm, maybe we should do something about that.

The code in _arguments takes care that the user-supplied specs are
preferred over the automatically derived ones, though.

Bye
 Sven


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

Re: _arguments parsing of --help output

[Bart Schaefer]

On Jul 24, 10:52am, Sven Wischnowsky wrote:
} Subject: Re: _arguments parsing of --help output
}
} Bart Schaefer wrote:
} 
} > Many GNU commands include short options in the --help output as well
} > [...] 
} > Is there a reason that we don't attempt to complete the short forms?
} 
}   _arguments '-e:ea:(1 2)' -e -b -p
} 
} This will make `foo -e <TAB>' complete `1' and `2' but `foo -' lists
} both (with auto-descriptions).

I don't understand here what you mean by "`foo -' lists both".

} The code in _arguments takes care that the user-supplied specs are
} preferred over the automatically derived ones, though.

Using the 3.1.9-dev-3 version of _arguments, I tried all of:

	_tst() { _arguments '--e:ea:(1 2)' -- }		# Case 1

	_tst() { _arguments -- '--e:ea:(1 2)' }		# Case 2

	_tst() { _arguments -- '*--e:ea:(1 2)' }	# Case 3

In combination with:

	tst() { print -l - --e --b --p }
	compdef _tst tst

Case 1: Completion after `tst' lists --e --b --p and completion after
`tst --e' lists 1 2.

Case 2: Completion after `tst' lists --e --b --p and completion after
`tst --e' completes `--' and then lists --b and --p; 1 or 2 are never
completed.

Case 3: Exactly like Case 2.

So case 1 behaves as I expected, and case 3 appears to be broken.  (I
also tried '*e:ea:(1 2)' and a few other patterns.)  I'm not sure what
I should be expecting from case 2.



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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net