Completion function for bitkeeper?

Completion function for bitkeeper?

[Steve Borho]

Before I go about trying to potentially re-invent someone's wheel, I
thought it would be prudent to ask:

Has anyone already written a completion function for bitkeeper with
similar level of sophistication as the cvs helper?


Now back to your previously interrupted daily dosage of SPAM...

-- 
Steve Borho

Re: Completion function for bitkeeper?

[Danek Duvall]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Fri, May 23, 2003 at 11:00:20AM -0500, Steve Borho wrote:

> Has anyone already written a completion function for bitkeeper with
> similar level of sophistication as the cvs helper?

Not quite, but you're welcome to complete (ha ha) what I've already
started, if you find it useful.  As I recall, it worked reasonably well
for what was there, but there were some bits, like setting flags, which
I couldn't get working quite properly.  There's plenty to do, if you
want to hack at it.

Files attached.

Danek

[-- Attachment #2: _bk --]
[-- Type: text/plain, Size: 9520 bytes --]

#compdef bk

local curcontext="$curcontext" state line
typeset -A opt_args
local subcmds ropt copt sfiles

subcmds=(
	abort admin annotate bin bkd c2r cat changes check checksum chmod
	ci citool clean clone cmdlog co comments commit config cp cset
	csetprune csets csettool deledit delget delta diffs difftool edit
	editor export extras findkey fix flags fmtool gca get gethost
	getuser gnupatch gone grep help helptool id ignore import info
	isascii key2rev level lock log makepatch merge multiuser mv mvdir
	names new newroot obscure parent path pending prompt prs pull push
	r2c range rcs2sccs rcsparse receive regression relink renames
	renametool renumber resolve resync revtool rm rmdel rmdir rmgone
	root rset sane sccscat sccslog send sendbug set setup setuptool
	sfiles sfio smerge status stripdel superset tag takepatch treediff
	undo undos unedit unlock unpull unrm unwrap users version what
	b64wrap gzip_b64wrap gzip_uuwrap uuwrap xflags zone
)

if [[ $service == "bk" ]]; then
	_arguments -C -A "-*" \
	'-R[change to the root of the repository]' \
	'-r-[apply to files beneath <dir>]::_files -W $(bk root)' \
	'-a[examine all files]' \
	'-c[list changed files]' \
	'-d[list directories with SCCS subdirectories]' \
	'-D[list directories without SCCS subdirectories]' \
	'-e[short for -jluvx]' \
	'-E[short for -cjluvxp]' \
	'-g[display gfile name]' \
	'-i[short for -cjlvxp]' \
	'-j[list junk files]' \
	'-l[list locked files]' \
	'-n[list files not in correct locations]' \
	'-p-[list files with pending deltas]: :(A C)' \
	'-S[display summary only]' \
	'-u[list unlocked files]' \
	'-U[list user files only]' \
	'-v[display info about the state of the s. file]' \
	'-x[list files without revision control files]' \
	'*::command:->subcmd' && return 0

	if (( CURRENT == 1 )); then
		_wanted commands expl 'BK command' compadd -a subcmds
		return
	fi
	service="$words[1]"
	curcontext="${curcontext%:*}=$service:"
fi

case $service in
	(abort)
		_arguments \
		'-f[force]' \
		'*:repository: _bk_repository'
	;;

	# -C, -M, -r, -y need actions
	# -y can only be used with -i and -n(?)
	(admin)
		_arguments \
		'-0[add 1.0 delta]' \
		'-C-[set or remove changeset file pointer]:ChangeSet file: ' \
		'-D[remove delta changeset marks]' \
		'-E-[set encoding]:encoding type:(text ascii binary)' \
		'*-f-[set flag]:flag:->setflag' \
		'*-F-[clear flag]:flag:->clearflag' \
		'-h[check (AT&T) SCCS s. file structure]' \
		'-hh[check (BK) SCCS s. file structure]' \
		'-hhh[check (BK) SCCS s. file structure and timestamps]' \
		'-H[check s. file structure]' \
		'-i-[read initial text]::file:_files' \
		'-m-[set mode]:mode: ' \
		'-M-[mark branch as merged]:revision: ' \
		'-p-[set path]::path:_files -W $(bk root)' \
		'-q[quiet]' \
		'-r-[specify revision]:revision: ' \
		'-S-[associate tag with revision]: :->settag' \
		'-t-[set description text from file]:file:_files' \
		'-T[clear description text]' \
		'-u[force monotonic timestamps]' \
		'-y-[set comment text for initial checkin]' \
		'-z[recalculate file checksum]' \
		'-Z-[set compression algorithm]:compression algorithm:(gzip none)' \
		'*:file:_sccsfiles'

		case $state in
			# These could be smart about what flags are already
			# set or not
			(setflag|clearflag)
				# local context state line
				# typeset -A val_args
				_values 'flags' \
				'BITKEEPER[mark as BitKeeper file]' \
				'DEFAULT[set default revision]:revision: ' \
				'EXPAND1[expand only first line with keywords]' \
				'EOLN_NATIVE[use native end-of-line termination]' \
				'MONOTONIC[file doesn'\''t roll back]' \
				'NOMERGE[don'\''t attempt to automerge]' \
				'RCS[expand RCS keywords]' \
				'SCCS[expand SCCS keywords]' \
				'YEAR4[display dates with 4 digit years]'
			;;
			# This obviously doesn't work quite right.
			(settag)
				_values 'tag=rev' \
				': :(4.1 4.2 4.3)'
			;;
		esac
	;;

	(annotate)
		_arguments \
		'-a[align prefix in human readable form]' \
		'-c-[annotate last version before this date]:date: ' \
		'-d[prefix line with date]' \
		'-k[suppress keyword expansion]' \
		'-m[prefix line with revision]' \
		'-N[prefix line with line number]' \
		'-n[prefix line with file name]' \
		'-r-[annotate this revision]:revision: ' \
		'-u[prefix line with user]' \
		'*:file:_sccsfiles'
	;;

	(bkd)
		_arguments \
		'-C[secure (refuse to cd out of repo)]' \
		'-d[run as daemon]' \
		'-D[debug mode]' \
		'-h[print HTTP headers]' \
		'-l-[logfile]' \
		'-P-[pidfile]' \
		'-p-[port]' \
		'-g-[gid]' \
		'-u-[uid]' \
		'-x-[exclude command]:command:(abort cd check clone get httpdget pull push pwd rclone rootkey status synckeys version)'
	;;

	(c2r)
		_arguments \
		'-r[revision]:revision: ' \
		'*:file:_sccsfiles'
	;;

	(changes)
		_arguments \
		'-/-[list changesets with matching comments]:string: ' \
		'-a[list all deltas]' \
		'(-L -R -r)-c-[specify changesets as date range]:date range: ' \
		'(-h)-d-[override default output format]:dspec: ' \
		'-e[show empty merge changesets]' \
		'-f[print changes in forward order]' \
		'(-d)-h[produce html as output]' \
		'-k[output matching changeset keys]' \
		'(-R -c -r)-L[list changesets unique to local repository]' \
		'-m[don'\''t show merge changesets]' \
		'-n[add a newline to each output record]' \
		'(-L -R -c)-r-[specify changesets as revision range]:revision range: ' \
		'(-L -c -r)-R[list changesets unique to remote repository]' \
		'-t[only list changesets which are tagged]' \
		'-u-[only list changesets created by user]:user: ' \
		'-U-[list changesets created by !user]:user: ' \
		'-v[show file change history]' \
		'*:repository: _bk_repository'
	;;

	(check)
		_arguments \
		'-a[ensures no discrepancies between ChangeSet and repo]' \
		'-c[check file and per-delta checksums]' \
		'-d[provide more details]' \
		'-e[check for end-of-line inconsistencies]' \
		'-f[fix any fixable errors]' \
		'-ff[fix any fixable errors (destructive)]' \
		'-g[list missing files]' \
		'-gg[list missing deltas]' \
		'-ggg[list missing files and missing deltas]' \
		'-p[list deltas in more than one changeset]' \
		'-R[only do checks which make sense in the RESYNC dir]' \
		'*-v[be verbose]' \
		'-w[list writable unlocked files]' \
		'*:file:_sccsfiles'
	;;

	(checksum)
		_arguments \
		'-f[fix missing or incorrect checksums]' \
		'-s-[generate checksum starting at <offset>]::offset: ' \
		'-v[verbose]' \
		'*:file:_sccsfiles'
	;;

	(chmod)
		_sccsfiles
	;;

	(ci)
		_arguments \
		'-f[force creation of null delta]' \
		'-i[check in new file]' \
		'-l[follow checkin with locked checkout]' \
		'-p[print differences before prompting for comments]' \
		'-q[quiet]' \
		'-u[follow checkin with unlocked checkout]' \
		'-y-[comment text]:comment' \
		'*:file:_sccsfiles -e'
	;;

	(citool)
	;;

	(clean)
		_arguments \
		'-p[print diffs for modified files]' \
		'-q[quiet]' \
		'-v[verbose]' \
		'*:file:_sccsfiles'
	;;

	# -r, -E need actions
	(clone)
		_arguments \
		'-E-[export environment variable]:variable=value: ' \
		'-l[user hard links]' \
		'-q[quiet]' \
		'-r-[changeset revision]' \
		'-z-[compression level]:compression level:compadd {0..9}'
	;;

	(cmdlog)
		_arguments \
		'-a[all commands]' \
		'-c-[commands during date range]:date range: '
	;;

	(co)
		_arguments \
		'-k[suppress keyword expansion]' \
		'-l[locked]' \
		'-p[print to stdout]' \
		'-q[quiet]' \
		'*:file:_sccsfiles'
	;;

	(comments)
		_arguments \
		'-r-[revision]:revision: ' \
		'-y-[comment text]:comment' \
		'-Y-[comment file]:comment' \
		'-C-[set all file comments on a changeset]:changeset: ' \
		'-p[generate list of all comments]' \
		'*:file:_sccsfiles'
	;;

	# Same as delta -l, delta -u
	(deledit|delget)
		_arguments \
		'-a[add new file if needed]' \
		'-C[use comments from SCCS/c.<file>]' \
		'-D-[take diffs from <file>]:file:_files' \
		'-E-[set encoding]:encoding type:(text ascii binary)' \
		'-h[invert sense of hash flag]' \
		'-I-[use <file> for meta data]:file:_files' \
		'-i[initial checkin]' \
		'-M-[set mode]:mode: ' \
		'-p[print diffs for modified files]' \
		'-q[quiet]' \
		'-Y[prompt for comment to be used on all files]' \
		'-y-[set comment text]' \
		'-Z-[set compression algorithm]:compression algorithm:(gzip none)' \
		'*:file:_sccsfiles -e'
	;;

	(delta)
		_arguments \
		'-a[add new file if needed]' \
		'-C[use comments from SCCS/c.<file>]' \
		'-D-[take diffs from <file>]:file:_files' \
		'-E-[set encoding]:encoding type:(text ascii binary)' \
		'-h[invert sense of hash flag]' \
		'-I-[use <file> for meta data]:file:_files' \
		'-i[initial checkin]' \
		'-l[follow checkin with locked checkout]' \
		'-M-[set mode]:mode: ' \
		'-p[print diffs for modified files]' \
		'-q[quiet]' \
		'-u[follow checkin with unlocked checkout]' \
		'-Y[prompt for comment to be used on all files]' \
		'-y-[set comment text]' \
		'-Z-[set compression algorithm]:compression algorithm:(gzip none)' \
		'*:file:_sccsfiles -e'
	;;

	(help)
		_arguments \
		'-a[search docs for topic string]' \
		'-f-[use file as helptext]:file:_files' \
		'-k[like -a, but match whole words]' \
		'-p[disable pager]' \
		'*:topic:_bk_helptopics'
	;;

	(sccscat)
		_arguments \
		'-a[align prefix in human readable form]' \
		'-c-[annotate versions in date range]:date: ' \
		'-d[prefix line with date]' \
		'-m[prefix line with revision]' \
		'-N[prefix line with line number]' \
		'-n[prefix line with file name]' \
		'-r-[annotate lines added by this revision]:revision: ' \
		'-u[prefix line with user]'
	;;

	(*)
		_message "unknown BK command: $service"
	;;
esac

[-- Attachment #3: _bk_helptopics --]
[-- Type: text/plain, Size: 436 bytes --]

#autoload +X

_bk_helptopics() {
	local -U topics
	local helpfile

	# This probably isn't the best way of checking to see if we need to
	# look at an alternate helpfile.
	if [[ ${#${(M)words:#-f*}} -ne 0 ]]; then
		print "Here" >> /tmp/blah
		helpfile=${${(M)words:#-f*}[-1]#-f}
	else
		helpfile=$(bk bin)/bkhelp.txt
	fi

	topics=( ${${${${${(f)"$(grep '^help://' $helpfile)"}#help://}%.(1|sum)}:#bk-*}:#*[/ ]*} )

	compadd -a topics
}

Re: Completion function for bitkeeper?

[Danek Duvall]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

I completely neglected to add the _sccsfiles function to the mail, and
now that I'm being asked about it again, I figure I should just send it
to the list.  :)

If someone can explain me out of my confusion in the first big comment,
that'd be really nice, but what I have appears to work.

Thanks,
Danek

[-- Attachment #2: _sccsfiles --]
[-- Type: text/plain, Size: 1461 bytes --]

#autoload +X

# %W% %E%

_sccsfiles () {
	local i=1 pfiles pdirs sfile="SCCS/s."

	# If _sccsfiles is called from one of the _sccs_* functions, then
	# it'll have some compadd options added after the first word, so
	# the positional parameters are not all "ours".
	#
	# One option is to precede the call to _sccsfiles in the optspec's
	# action with a space, which prevents these extra parameters from
	# being passed in.  Ugh.  See the documentation for _arguments in
	# zshcompsys(1), where it talks about action starting with a space.
	#
	# Instead, remove the first few arguments if they match $expl.  Why
	# they're passed in both places I don't know (and this may be a
	# bug).

	while [[ -n "$1" && "$1" == "$expl[i]" ]]; do
		shift
		((++i))
	done

	[[ "$1" == "-e" ]] && sfile="SCCS/p."

	compset -P "*/"

	# Add matching files
	pfiles=( ${IPREFIX}${sfile}${PREFIX}*(.N) )
	pfiles=( ${pfiles/${IPREFIX}${sfile}} )
	compadd -af pfiles

	# Add matching directories
	# This should be made more efficient to only descend as far as
	# necessary in each directory to find an s. file.
	if [[ -z ${PREFIX} ]]; then
		pdirs=( ${IPREFIX}**/${sfile}*(.N) )
	else
		pdirs=( ${IPREFIX}${PREFIX}*/**/${sfile}*(.N) )
	fi

	# Remove IPREFIX, then only take first-level directory
	pdirs=( ${^${pdirs/${IPREFIX}}%%/*} )
	# Remove SCCS directories
	pdirs=( ${pdirs:#SCCS} )

	compadd -aq -S / pdirs

	# Explicitly return success as the above may have failed.
	return 0
}

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Danek Duvall wrote:
> 
> If someone can explain me out of my confusion in the first big comment,
> that'd be really nice, but what I have appears to work.

> 	# If _sccsfiles is called from one of the _sccs_* functions, then
> 	# it'll have some compadd options added after the first word, so
> 	# the positional parameters are not all "ours".
> 	#
> 	# One option is to precede the call to _sccsfiles in the optspec's
> 	# action with a space, which prevents these extra parameters from
> 	# being passed in.  Ugh.  See the documentation for _arguments in
> 	# zshcompsys(1), where it talks about action starting with a space.
> 	#
> 	# Instead, remove the first few arguments if they match $expl.  Why
> 	# they're passed in both places I don't know (and this may be a
> 	# bug).
> 
> 	while [[ -n "$1" && "$1" == "$expl[i]" ]]; do
> 		shift
> 		((++i))
> 	done
>
> 	[[ "$1" == "-e" ]] && sfile="SCCS/p."

Try using zparseopts to find and remove that -e option instead:
  zparseopts -D -E e=eopt
  [[ -n $eopt ]] && sfile="SCCS/p."

Looking inside expl is not a good idea as the array name expl is purely
a convention.

The other thing you can do is use a `-' in the _sccs_* functions from
which you call _sccsfiles. e.g:
  _wanted files expl 'sccs file' _sccsfiles -e -

It will then put compadd options after the `-e'. The main use of that
however is when you have "$@" among the arguments and want any
description in it to take precedence over the new one.

Oliver

Re: Completion function for bitkeeper?

[Danek Duvall]

On Fri, Nov 07, 2003 at 08:17:45PM +0100, Oliver Kiddle wrote:

> Looking inside expl is not a good idea as the array name expl is
> purely a convention.

I agree that if it's merely a convention that I shouldn't use it.
However, the zshcompsys man page explicitly documents it, suggesting
that it's safe to use.  If it's not, perhaps removing it from the
documentation is the right thing to do.

> Try using zparseopts to find and remove that -e option instead:
>   zparseopts -D -E e=eopt
>   [[ -n $eopt ]] && sfile="SCCS/p."

That works, thanks.

Still, this whole thing feels like a fragile interface.  Two entirely
different sets of information are being passed to the function on the
commandline, which at the very least means that there's a potential for
flag collision (what happens if _arguments decides to pass in -e for
compadd purposes?), never mind the parsing difficulties.

It seems that using some other method for passing in compadd arguments
would be better ... such as using a well-known parameter name.  :)

I still maintain that passing in the compadd arguments both on the
commandline and in $expl is a bug, as it's duplicative, redundant,
repetitive, and redundant.

Danek

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Danek Duvall wrote:

> I agree that if it's merely a convention that I shouldn't use it.
> However, the zshcompsys man page explicitly documents it, suggesting
> that it's safe to use.  If it's not, perhaps removing it from the
> documentation is the right thing to do.

Searching for expl in zshcompsys, it is only used in examples. The one
exception is in the context of _arguments actions where it isn't just a
convention (_arguments can't use positional parameters for actions). I
certainly can't see anywhere where it suggests that you can expect it
to be set by a calling function.

> Still, this whole thing feels like a fragile interface.  Two entirely
> different sets of information are being passed to the function on the
> commandline, which at the very least means that there's a potential for
> flag collision (what happens if _arguments decides to pass in -e for
> compadd purposes?), never mind the parsing difficulties.

The two entirely different sets of information system isn't ideal but
the positional parameters are the most convenient place for passing
information around.

The best alternative I can think of would be to have the tag loop
function store the compadd options for each level of tag nesting and
not use positional parameters for compadd options. Tag loops need
rethinking anyway due to problems with label loops being separate.

For now completion functions should avoid certain compadd options for
passing other information. zparseopts tends to make it easy enough to
follow this. If you really want lots of options, follow _arguments and
have a `-O array' option for passing compadd options.

> It seems that using some other method for passing in compadd arguments
> would be better ... such as using a well-known parameter name.  :)
> 
> I still maintain that passing in the compadd arguments both on the
> commandline and in $expl is a bug, as it's duplicative, redundant,
> repetitive, and redundant.

compadd arguments aren't passed in $expl. They may coincidentally
happen to be lying around in $expl but only because $expl was chosen as
a place to have _description store them temporarily before passing them
on.

Oliver

Re: Completion function for bitkeeper?

[Peter Stephenson]

Oliver Kiddle wrote:
> compadd arguments aren't passed in $expl. They may coincidentally
> happen to be lying around in $expl but only because $expl was chosen as
> a place to have _description store them temporarily before passing them
> on.

The subtlety of the distinction is a bit lost on me.  Isn't that exactly
the problem Danek is worried about?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Peter wrote:
> Oliver Kiddle wrote:
> > compadd arguments aren't passed in $expl. They may coincidentally
> > happen to be lying around in $expl but only because $expl was chosen as
> > a place to have _description store them temporarily before passing them
> > on.
> 
> The subtlety of the distinction is a bit lost on me.  Isn't that exactly
> the problem Danek is worried about?

I would only share Danek's worry if it was undefined as to where a
function should go looking for compadd options passed to it. It isn't
undefined - compadd options are only explicitly passed to other
completion functions in the positional parameters.

If we take this example:

_foo() {
  local expl
  _description foo expl foos
  _bar "$expl[@]"
}

As a result of zsh having dynamic scoping, _foo's $expl is still
visible inside _bar. _foo happens to use $expl for storing compadd
options to pass on. Knowing this the author of _bar could take
advantage of it but it'd be bad programming (and might break if _bar
was called from elsewhere). To actively prevent it, we need static
scoping.

Does that make sense now?

Oliver

PS. As an aside, needing the expl parameter to _wanted is somewhat
pointless.

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

Re: Completion function for bitkeeper?

[Peter Stephenson]

Oliver Kiddle wrote:
> _foo() {
>   local expl
>   _description foo expl foos
>   _bar "$expl[@]"
> }
> 
> As a result of zsh having dynamic scoping, _foo's $expl is still
> visible inside _bar. _foo happens to use $expl for storing compadd
> options to pass on. Knowing this the author of _bar could take
> advantage of it but it'd be bad programming (and might break if _bar
> was called from elsewhere). To actively prevent it, we need static
> scoping.

Hmm... isn't the problem that the $expl set at this point and passed
down to _bar ultimately ends up getting passed to compadd (maybe
indirectly), while _bar may add its own options?  I've seen this sort of
thing when trying to sort out the sorting, i.e. the -J and -V options to
compadd.  Often one of them's already lurking in $expl at the point
where I want to propagate my choice of option down through the system.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Peter wrote:

> Hmm... isn't the problem that the $expl set at this point and passed
> down to _bar ultimately ends up getting passed to compadd (maybe
> indirectly), while _bar may add its own options?  I've seen this sort of

It never should be passed to compadd. _bar or some other function would
have to use $expl without declaring it local and setting it itself.

If you've seen problems, there must be a missing local declaration for
expl somewhere.

If you look inside _all_labels and _description, you will see that any
existing value in expl (assuming that is what is passed as the name
parameter) is thrown away with the new value assigned to it. So the
only way that an old $expl can get used is by some other completion
function using "$expl[@]" without declaring expl local.

expl is only ever intended to be used temporarily. It is not part of
any mechanism by which information is passed down through the
completion system.

> thing when trying to sort out the sorting, i.e. the -J and -V options to
> compadd.  Often one of them's already lurking in $expl at the point
> where I want to propagate my choice of option down through the system.

Are you sure it isn't lurking in the positional parameters.

Oliver

Re: Completion function for bitkeeper?

[Peter Stephenson]

> > thing when trying to sort out the sorting, i.e. the -J and -V options to
> > compadd.  Often one of them's already lurking in $expl at the point
> > where I want to propagate my choice of option down through the system.
> 
> Are you sure it isn't lurking in the positional parameters.

Ah, that's probably what I mean.  `_bar "$expl[@]"' passes down -J or -V
(any local expl inside _bar is irrelevant, of course) and I have to
decide whether to pass that down, or somehow replace bits of the
argument list.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Completion function for bitkeeper?

[Danek Duvall]

On Tue, Nov 11, 2003 at 09:22:57AM +0100, Oliver Kiddle wrote:

> Searching for expl in zshcompsys, it is only used in examples. The one
> exception is in the context of _arguments actions where it isn't just a
> convention (_arguments can't use positional parameters for actions).

And as an action in _arguments is exactly how I'm using the _sccsfiles
function.  See my posting from May 23 that includes the _bk script.

I'm not sure what you mean by your parenthetical statement.  My action
certainly does have positional parameters passed to it, some of which
are the ones I specify as its arguments in my call to _arguments, some
of which are passed in without my telling them to be.

> I certainly can't see anywhere where it suggests that you can expect
> it to be set by a calling function.

Except by _arguments.

> The two entirely different sets of information system isn't ideal but
> the positional parameters are the most convenient place for passing
> information around.

Then why in $expl in the single case of _arguments?

> For now completion functions should avoid certain compadd options for
> passing other information. zparseopts tends to make it easy enough to
> follow this. If you really want lots of options, follow _arguments and
> have a `-O array' option for passing compadd options.

Hm.  I just saw that.  So in addition to the documented methods of using
$expl in an action of _arguments to get compadd args and using some of
the positional parameters, there's also the suggested method of passing
them in through -O?  What a wealth!

> compadd arguments aren't passed in $expl.

Except from _arguments (not to belabor the point or anything ;-).

Thanks,
Danek

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Peter wrote:

> Ah, that's probably what I mean.  `_bar "$expl[@]"' passes down -J or -V
> (any local expl inside _bar is irrelevant, of course) and I have to
> decide whether to pass that down, or somehow replace bits of the
> argument list.

Yes. Can be a bit of a juggling act to deal with the options because it
varies which you want to pass on, which to remove and which to replace
etc.

Oliver

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Danek Duvall wrote:
> On Tue, Nov 11, 2003 at 09:22:57AM +0100, Oliver Kiddle wrote:
> 
> > Searching for expl in zshcompsys, it is only used in examples. The one
> > exception is in the context of _arguments actions where it isn't just a
> > convention (_arguments can't use positional parameters for actions).
> 
> And as an action in _arguments is exactly how I'm using the _sccsfiles
> function.  See my posting from May 23 that includes the _bk script.

Sorry, I should have been more clear. What I mean is actually in the
_arguments action itself not within a function called as part of the
action. Looking at the documentation, it isn't as clear on this as it
should be. It doesn't help that in the rearrangement of the
documentation, the expl mention has become separated from the
`{eval-string}' action form and a little from the initial space feature
(have a look at 4.0 documentation).

Basically, it is intended so you can do things like this:

  '-a:desc: _foo -x -y -z "$expl[@]" a b c'
  '-b:desc:{compadd "$expl[@]" one two three}'

(the initial space before _foo prevents _arguments from automatically
putting explanation options after `_foo'.)

It is not intended so that with a specification like:
  '-a:desc:_sccs_files'
_sccs_files can then look in expl.

Any ideas on how to make the documentation clearer on this? Thanks for
raising the issue.

> Hm.  I just saw that.  So in addition to the documented methods of using
> $expl in an action of _arguments to get compadd args and using some of
> the positional parameters, there's also the suggested method of passing
> them in through -O?  What a wealth!

That is only for passing compadd options to _arguments. I don't
personally like it much though.

How's that bitkeeper function doing these days by the way? Is it at a
stage we could include with zsh? Does it conflict with _sccs?

Oliver

Re: Completion function for bitkeeper?

[Danek Duvall]

On Tue, Nov 11, 2003 at 08:06:12PM +0100, Oliver Kiddle wrote:

> Sorry, I should have been more clear. What I mean is actually in the
> _arguments action itself not within a function called as part of the
> action. Looking at the documentation, it isn't as clear on this as it
> should be. It doesn't help that in the rearrangement of the
> documentation, the expl mention has become separated from the
> `{eval-string}' action form and a little from the initial space
> feature (have a look at 4.0 documentation).
> 
> Basically, it is intended so you can do things like this:
> 
>   '-a:desc: _foo -x -y -z "$expl[@]" a b c'
>   '-b:desc:{compadd "$expl[@]" one two three}'

Okay, I see what you mean now.  It's not intended for $expl here to be
visible inside the function that's called, but it is, because of the
scoping issues you and Peter are talking about.

Is there any reason (other than it would break code relying on the
current behavior) not to just require someone to explicitly add $expl to
the action, so that they can control where it goes?  You can do that now
by prefixing with a space, but ... that just seems a bit silly to me ...
too much automation for a case that doesn't really require it.  But now
that I understand it, I guess I can live with it.

> Any ideas on how to make the documentation clearer on this?

I'm not sure.  I think what made it click for me was your example above.
Perhaps saying that

    '-a:desc:_foo -x -y -z a b c'

is equivalent to

    '-a:desc: _foo "$expl[@]" -x -y -z a b c'

as a "that is" statement somewhere in that paragraph would be helpful?
Getting rid of the automatic passing would certainly help make the
documentation easier to write here.  <grin>

The root of the problem is that I was getting arguments in my function
called from the action that I didn't know how to deal with, and I didn't
know how to ignore, other than putting the initial space in, which felt
like a kludge, or possibly the wrong answer.

If that's the only confusion that needs to be addressed, perhaps we
could say that if a function called as an action wants to do argument
parsing, it may have difficulty because of the options passed to it by
_arguments.  Such a function should probably be called in an action
starting with a space to avoid the problem, and $expl[@] be passed
explicitly in such a way that the function can handle extracting those
arguments from the non-compadd related ones.

Then, if you really wanted to lay it on thick, you could also mention
that trying to extract the contents of $expl as _arguments sees it from
within the function is not supported, and that it only works because
there's currently no way to prevent the function from inheriting it from
_arguments, but that may change at some point in the future.

> How's that bitkeeper function doing these days by the way? Is it at a
> stage we could include with zsh? Does it conflict with _sccs?

Well, none of the usual zsh folks commented on it, so while it works for
me, I don't feel it's undergone much review.  There's some work that
still needs to be done, I think:

  - flesh out all the bk sub-commands; not all of them have clauses in
    _bk yet
  - there are a number of comments in the function that indicate things
    I couldn't quite figure out what to do
  - I don't think that it conflicts with _sccs at all, but it might be
    nice to get _sccs to use _sccsfiles in the appropriate places.
  - _sccsfiles probably should have some way of controlling the depth to
    which it searches for matches.  Currently, it just does **/ and if
    that has to search through tens of thousands of files and
    directories, then you're just going to have to wait, and I don't
    think that's necessarily the best behavior.  Suggestions for more
    appropriate behavior would be greatly appreciated.

Other than that, I'm perfectly happy for any of this stuff to get into
the tree.

Thanks,
Danek

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Danek Duvall wrote:

> Is there any reason (other than it would break code relying on the
> current behavior) not to just require someone to explicitly add $expl to
> the action, so that they can control where it goes?  You can do that now

Having $expl stuff added after the first word is exactly the behaviour
that is wanted in virtually 100% of all cases. If you do a search on
completion functions, the $expl feature is never used and the initial
space feature is very rarely used (and where it is may not have been
intentional). And, it would break existing code (and be a very boring
job to add to existing code).

However, it does seem redundant having both the initial space and
braces feature.

For '*:desc:{_foo}' style actions, this is run:

  eval "$action[@]"

and for '*:desc: _foo', this is run:

  eval "action=( $action )"
  "$action[@]"

Can anyone tell me what practical difference that makes, if any?

What might be a good plan is to deprecate the initial space feature and
then, by only documenting expl under the {eval-string} form of action,
it will be easier make things clear in the documentation.

> > How's that bitkeeper function doing these days by the way? Is it at a
> > stage we could include with zsh? Does it conflict with _sccs?
> 
> Well, none of the usual zsh folks commented on it, so while it works for

I suspect none of the usual zsh folks use bitkeeper.

>   - there are a number of comments in the function that indicate things
>     I couldn't quite figure out what to do

If you send me your latest version, I'll take a look.

>   - I don't think that it conflicts with _sccs at all, but it might be
>     nice to get _sccs to use _sccsfiles in the appropriate places.

I'll be interested to see if that does anything useful for sccs. I use
Sun teamware at work which is sccs underneath so I do use the sccs
completion.

Oliver

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

Re: Completion function for bitkeeper?

[Peter Stephenson]

Oliver Kiddle wrote:
> For '*:desc:{_foo}' style actions, this is run:
> 
>   eval "$action[@]"
> 
> and for '*:desc: _foo', this is run:
> 
>   eval "action=( $action )"
>   "$action[@]"
> 
> Can anyone tell me what practical difference that makes, if any?
> 
> What might be a good plan is to deprecate the initial space feature and
> then, by only documenting expl under the {eval-string} form of action,
> it will be easier make things clear in the documentation.

I don't think we *need* both, and the brace is clearer --- more to the
point, use of the space is almost completely opaque, plus it's hard to
search for in the documentation.  So switching the code makes sense.
However, we might need a pointer in case people wonder about it, and
since the documentation consists of one sentence it's not clear how much
difference it makes to change it there (except to say it's deprecated).

What about a single unquoted space to indicate no matches?  Why do we
need the space at all?  Surely if there's nothing there it indicates no
possible matches?  It's all a bit Zen-like.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Peter wrote:
 
> I don't think we *need* both, and the brace is clearer --- more to the
> point, use of the space is almost completely opaque, plus it's hard to
> search for in the documentation.  So switching the code makes sense.
> However, we might need a pointer in case people wonder about it, and
> since the documentation consists of one sentence it's not clear how much
> difference it makes to change it there (except to say it's deprecated).

Do we need to actually say it's deprecated? Can't we just remove that
part of the documentation and add a bit under the brace form about
expl. We can mention in the next release note and in a comment inside
_arguments that the feature is deprecated.

> What about a single unquoted space to indicate no matches?  Why do we
> need the space at all?  Surely if there's nothing there it indicates no
> possible matches?  It's all a bit Zen-like.

Yes, that's also pointless. Virtually nobody bothers to use it anyway.
Leaving the action empty is what most people have done (though varying
on whether to include the trailing colon). So we can get rid of that
from the documentation too.

I'll come up with a patch this weekend. Including finding all
the places we've used the initial space in existing functions.

Oliver

Re: Completion function for bitkeeper?

[Danek Duvall]

On Fri, Nov 14, 2003 at 09:04:56AM +0100, Oliver Kiddle wrote:

> Having $expl stuff added after the first word is exactly the behaviour
> that is wanted in virtually 100% of all cases.

So let me ask, what am I doing wrong that makes me believe that I don't
want it in my case?  Is there a conventional way of passing arguments to
an action helper function and not getting them mixed up with arguments
intended for compadd?  Is there functionality I'm missing because I'm
not doing the conventional thing?

> > > How's that bitkeeper function doing these days by the way? Is it
> > > at a stage we could include with zsh? Does it conflict with _sccs?
> > 
> > Well, none of the usual zsh folks commented on it, so while it works for
> 
> I suspect none of the usual zsh folks use bitkeeper.

That may be the case; I still might have expected some comments on
style, missing functionality (like I'm not passing anything to compadd ;-)
or things completely unrelated to bitkeeper.

> If you send me your latest version, I'll take a look.

I'll send that out later today.

> >   - I don't think that it conflicts with _sccs at all, but it might be
> >     nice to get _sccs to use _sccsfiles in the appropriate places.
> 
> I'll be interested to see if that does anything useful for sccs. I use
> Sun teamware at work which is sccs underneath so I do use the sccs
> completion.

As do I (I actually use it primarily; I hardly touch bk), so I do have a
version of _sccs that uses _sccsfiles.  It's not completely useless.  :)

Danek

Re: Completion function for bitkeeper?

[Bart Schaefer]

On Nov 14, 10:47am, Peter Stephenson wrote:
} Subject: Re: Completion function for bitkeeper?
}
} Oliver Kiddle wrote:
} > For '*:desc:{_foo}' style actions, this is run:
} > 
} >   eval "$action[@]"
} > 
} > and for '*:desc: _foo', this is run:
} > 
} >   eval "action=( $action )"
} >   "$action[@]"
} > 
} > Can anyone tell me what practical difference that makes, if any?

Word splitting is vastly different in the two cases.  It happens within
the words of $action in the second case, but does not in the first case.

Also in the second example, only "alias -g" aliases are expanded.  Not
that I think that was the intended behavior, but ...

} I don't think we *need* both

Yes, we do.  There are uses for that splitting behavior.

} What about a single unquoted space to indicate no matches?  Why do we
} need the space at all?  Surely if there's nothing there it indicates no
} possible matches?  It's all a bit Zen-like.

There's a reason for that, too, but I'll have to dig in the archives a
bit to find it.

Re: Completion function for bitkeeper?

[Peter Stephenson]

Bart Schaefer wrote:
> Word splitting is vastly different in the two cases.  It happens within
> the words of $action in the second case, but does not in the first case.

Oliver simplified a bit; there's an eval in the first case as well,
which complicates the issue:

              elif [[ "$action" = \{*\} ]]; then

                # A string in braces is evaluated.

                while _next_label "$subc" expl "$descr"; do
                  eval "$action[2,-2]" && ret=0
                done
                (( ret )) && alwopt=${alwopt:-yes}
	        tried=yes
              elif [[ "$action" = \ * ]]; then

                # If the action starts with a space, we just call it.

	        eval "action=( $action )"
                while _next_label "$subc" expl "$descr"; do
                  "$action[@]" && ret=0
                done
                (( ret )) && alwopt=${alwopt:-yes}
	        tried=yes

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Bart wrote:

> } > For '*:desc:{_foo}' style actions, this is run:
> } > 
> } >   eval "$action[@]"
> } > 
> } > and for '*:desc: _foo', this is run:
> } > 
> } >   eval "action=( $action )"
> } >   "$action[@]"
> } > 
> } > Can anyone tell me what practical difference that makes, if any?

> Word splitting is vastly different in the two cases.  It happens within
> the words of $action in the second case, but does not in the first case.

Really? As far as I can see, they both get exactly the same word
splitting:

% a=( print -l one two three\ four 'five\ six' )
% eval "$a[@]"
one
two
three
four
five six

% eval "b=( $a )"
% "$b[@]"
one
two
three
four
five six

> Also in the second example, only "alias -g" aliases are expanded.  Not
> that I think that was the intended behavior, but ...

That's odd. But, as we're using autoload -U, that has no effect on
_argumemts. 

Oliver

Re: Completion function for bitkeeper?

[Bart Schaefer]

[This should move to zsh-workers?]

On Nov 14,  4:23pm, Peter Stephenson wrote:
} Subject: Re: Completion function for bitkeeper?
}
} Bart Schaefer wrote:
} > Word splitting is vastly different in the two cases.  It happens within
} > the words of $action in the second case, but does not in the first case.

That's a bit incoherent, let me try again.

Consider what happens when there are command separators in the values of
$action.  Suppose e.g. that

	action=( \{ foo '&&' bar \} )

}                 while _next_label "$subc" expl "$descr"; do
}                   eval "$action[2,-2]" && ret=0
}                 done

In the above case we execute the equivalent of

	foo && bar && ret=0

However, if instead

	action=( ' ' foo '&&' bar )

} 	        eval "action=( $action )"
}                 while _next_label "$subc" expl "$descr"; do
}                   "$action[@]" && ret=0
}                 done

In this second case it's a syntax error.  I suppose it could be argued
that the second case is unnecessary because it's only a shorthand for
the first case with only one command in the braces.

Also in the second case the eval has been factored out of the loop
because we're always interested in the entire value of "$action" and
it's fractionally more efficient to do the "eval" once only.

However, on third thought, it could be argued that the second case has
a bug.  Consider

	action=( " foo ) && bar=( oops" )

Re: Completion function for bitkeeper?

[Danek Duvall]

Here are the bitkeeper and sccs functions I use.

    http://lorien.emufarm.org/~duvall/zsh/

Some caveats:

  - _bk is incomplete (not all subcommands have logic for them, and
    _bk_repository is not written)
  - not all _bk functionality is correct -- there are some cases where I
    couldn't figure out what bk's actual behavior was, so it was unclear
    what I was trying to model, and there were some cases where I wasn't
    sure how to model the behavior correctly.  These should all be
    marked with comments.
  - I'm not sure what version of bk this is against.  3.0.1, I think.
  - _sccs was written by myself, I think before _sccs was in the tree.
    Feel free to grab anything from that which might be useful.
  - sccsdiff and sccshist are just simple functions to help view sccs
    revision histories.

Danek

Re: Completion function for bitkeeper?

[Oliver Kiddle]

On 14 Nov, Danek Duvall wrote:
> 
> > Having $expl stuff added after the first word is exactly the behaviour
> > that is wanted in virtually 100% of all cases.
> 
> So let me ask, what am I doing wrong that makes me believe that I don't
> want it in my case?  Is there a conventional way of passing arguments to
> an action helper function and not getting them mixed up with arguments
> intended for compadd?  Is there functionality I'm missing because I'm
> not doing the conventional thing?

You're not doing something wrong so much as different. Firstly, the
most common case is that there are no options other than compadd
options to get mixed up with so having $expl added is what is wanted.

You wanted the compadd options after your own extra option because it
made it easier to find your option--it would always be the first one.
That made your helper function simpler but puts the onus on the calling
functions to get the options in the right order.

Normally, we put the onus on the helper function to sort out mixed up
options and we have zparseopts to make the job easy. That's better in
my opinion. If you found a Unix program which had two independent and
unrelated options -a and -b and the program couldn't cope with them
being specified in the order -b followed by -a, you wouldn't think it
was very good would you?

Does that make sense?

Oliver 

Re: Completion function for bitkeeper?

[Danek Duvall]

On Mon, Nov 17, 2003 at 04:47:40PM +0100, Oliver Kiddle wrote:

> You're not doing something wrong so much as different.

People have been telling me this all my life.  ;-)

> Firstly, the most common case is that there are no options other than
> compadd options to get mixed up with so having $expl added is what is
> wanted.

Fair enough; I certainly understand that.

> You wanted the compadd options after your own extra option because it
> made it easier to find your option--it would always be the first one.
> That made your helper function simpler but puts the onus on the
> calling functions to get the options in the right order.

Well, not just that it would be easier to find my option, but that my
option would be findable at all.

As it is, even with zparseopts (which I hadn't known about, so thank you
for that), there's no way at all to tell whether a -e that's passed to
my helper function is there because I passed it in explicitly through an
argument to _arguments, or whether it's part of the set of arguments
that's destined only for compadd.  There's simply no way for me to know.

So then the onus is on me to pick a flag that compadd doesn't already
use.  It uses seventeen uppercase letters, thirteen lowercase letters,
and two numbers, and that's a pretty severe depletion of the usable
namespace of flags.  But assuming I choose one (and it's even remotely
mnemonic), then there's no guarantee that a future release doesn't add a
new flag to compadd, and bites me in the ass!

So while I understand your explanation, my question of how to do this
right is still going unanswered.

One answer I can think of is to avoid the use of command-line flags
entirely, and just have two different functions.  Three probably -- one
is the function as it currently is, and two wrapper functions that call
the the first either with or without a flag.  Then they'd be
distinguished by different names.  A global shell variable is another
answer.  But these just seem kludgey to me.

> If you found a Unix program which had two independent and unrelated
> options -a and -b and the program couldn't cope with them being
> specified in the order -b followed by -a, you wouldn't think it was
> very good would you?

Of course not, but that's not the problem at hand.  It's not ordering
that's the problem, it's overlapping namespaces.  And by the time my
function sees the result, the overlap is no longer undoable.  It's like
merging image layers in GIMP or Photoshop -- you can't reconstruct the
layers from the merged result, so you don't know which pixels came from
which layer, so you've lost information.

Danek

Re: Completion function for bitkeeper?

[Oliver Kiddle]

Danek Duvall wrote:

> As it is, even with zparseopts (which I hadn't known about, so thank you
> for that), there's no way at all to tell whether a -e that's passed to
> my helper function is there because I passed it in explicitly through an
> argument to _arguments, or whether it's part of the set of arguments
> that's destined only for compadd.  There's simply no way for me to know.

-e will only ever be there if you passed it explicitly. Though -e is an
option to compadd, it really wouldn't make sense to pass it to a
completion function. So you're safe with -e. Admittedly you would
not be safe had you chosen -x.

> So then the onus is on me to pick a flag that compadd doesn't already
> use.  It uses seventeen uppercase letters, thirteen lowercase letters,
> and two numbers, and that's a pretty severe depletion of the usable
> namespace of flags.  But assuming I choose one (and it's even remotely

A good few are safe to use: -a, -k, -f, -e, -W and -U are all safe. I'm
not sure about some such as -l, -Q, -C and -E without looking in more
detail. That perhaps should be documented somewhere.

> mnemonic), then there's no guarantee that a future release doesn't add a
> new flag to compadd, and bites me in the ass!

No there isn't but no compadd options have been added in a long while.
We can do a search on distributed functions if we do ever add one.

> So while I understand your explanation, my question of how to do this
> right is still going unanswered.

I think I've now explained how best to do this given the constraints of
the completion system as it currently stands.

I agree that it isn't ideal. The best alternative I can think of would
be to pass compadd options to the various tag handling functions
instead of the completion functions. Tag loops need rethinking anyway
and that isn't a trivial job. Discussion of possible changes to compsys
should go to zsh-workers, though.

Oliver