zsh-workers
 help / color / mirror / code / Atom feed
* Re: _arguments parsing of --help output
@ 2000-07-24  8:52 Sven Wischnowsky
  2000-07-25 15:05 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 2000-07-24  8:52 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: _arguments parsing of --help output
  2000-07-24  8:52 _arguments parsing of --help output Sven Wischnowsky
@ 2000-07-25 15:05 ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2000-07-25 15:05 UTC (permalink / raw)
  To: Sven Wischnowsky, zsh-workers

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   


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: _arguments parsing of --help output
  2000-07-21 22:22 Bart Schaefer
@ 2000-07-21 23:10 ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2000-07-21 23:10 UTC (permalink / raw)
  To: zsh-workers

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* _arguments parsing of --help output
@ 2000-07-21 22:22 Bart Schaefer
  2000-07-21 23:10 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 2000-07-21 22:22 UTC (permalink / raw)
  To: zsh-workers

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)//\[--/
--}:#[ 	]#-*}//,/
}:#[ 	]#-*}#*-}%%[]	 ]*}:#}")


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-07-25 15:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-24  8:52 _arguments parsing of --help output Sven Wischnowsky
2000-07-25 15:05 ` Bart Schaefer
  -- strict thread matches above, loose matches on Subject: below --
2000-07-21 22:22 Bart Schaefer
2000-07-21 23:10 ` Bart Schaefer

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