* Completion function for bitkeeper? @ 2003-05-23 16:00 Steve Borho 2003-05-23 16:01 ` Danek Duvall 0 siblings, 1 reply; 27+ messages in thread From: Steve Borho @ 2003-05-23 16:00 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-05-23 16:00 Completion function for bitkeeper? Steve Borho @ 2003-05-23 16:01 ` Danek Duvall 2003-11-06 15:32 ` Danek Duvall 0 siblings, 1 reply; 27+ messages in thread From: Danek Duvall @ 2003-05-23 16:01 UTC (permalink / raw) To: Steve Borho; +Cc: zsh-users [-- 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 } ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-05-23 16:01 ` Danek Duvall @ 2003-11-06 15:32 ` Danek Duvall 2003-11-07 19:17 ` Oliver Kiddle 0 siblings, 1 reply; 27+ messages in thread From: Danek Duvall @ 2003-11-06 15:32 UTC (permalink / raw) To: zsh-users; +Cc: Jonas Juselius [-- 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 } ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-06 15:32 ` Danek Duvall @ 2003-11-07 19:17 ` Oliver Kiddle 2003-11-10 18:20 ` Danek Duvall 0 siblings, 1 reply; 27+ messages in thread From: Oliver Kiddle @ 2003-11-07 19:17 UTC (permalink / raw) To: Danek Duvall; +Cc: Jonas Juselius, zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-07 19:17 ` Oliver Kiddle @ 2003-11-10 18:20 ` Danek Duvall 2003-11-11 8:22 ` Oliver Kiddle 0 siblings, 1 reply; 27+ messages in thread From: Danek Duvall @ 2003-11-10 18:20 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Jonas Juselius, zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-10 18:20 ` Danek Duvall @ 2003-11-11 8:22 ` Oliver Kiddle 2003-11-11 10:42 ` Peter Stephenson 2003-11-11 16:23 ` Danek Duvall 0 siblings, 2 replies; 27+ messages in thread From: Oliver Kiddle @ 2003-11-11 8:22 UTC (permalink / raw) To: Danek Duvall; +Cc: Jonas Juselius, zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 8:22 ` Oliver Kiddle @ 2003-11-11 10:42 ` Peter Stephenson 2003-11-11 15:21 ` Oliver Kiddle 2003-11-11 16:23 ` Danek Duvall 1 sibling, 1 reply; 27+ messages in thread From: Peter Stephenson @ 2003-11-11 10:42 UTC (permalink / raw) To: zsh-users 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 ********************************************************************** ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 10:42 ` Peter Stephenson @ 2003-11-11 15:21 ` Oliver Kiddle 2003-11-11 15:24 ` Peter Stephenson 0 siblings, 1 reply; 27+ messages in thread From: Oliver Kiddle @ 2003-11-11 15:21 UTC (permalink / raw) To: zsh-users 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 ________________________________________________________________________ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 15:21 ` Oliver Kiddle @ 2003-11-11 15:24 ` Peter Stephenson 2003-11-11 16:13 ` Oliver Kiddle 0 siblings, 1 reply; 27+ messages in thread From: Peter Stephenson @ 2003-11-11 15:24 UTC (permalink / raw) To: zsh-users 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 ********************************************************************** ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 15:24 ` Peter Stephenson @ 2003-11-11 16:13 ` Oliver Kiddle 2003-11-11 16:23 ` Peter Stephenson 0 siblings, 1 reply; 27+ messages in thread From: Oliver Kiddle @ 2003-11-11 16:13 UTC (permalink / raw) To: Zsh users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 16:13 ` Oliver Kiddle @ 2003-11-11 16:23 ` Peter Stephenson 2003-11-11 16:44 ` Oliver Kiddle 0 siblings, 1 reply; 27+ messages in thread From: Peter Stephenson @ 2003-11-11 16:23 UTC (permalink / raw) To: Zsh users > > 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 ********************************************************************** ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 16:23 ` Peter Stephenson @ 2003-11-11 16:44 ` Oliver Kiddle 0 siblings, 0 replies; 27+ messages in thread From: Oliver Kiddle @ 2003-11-11 16:44 UTC (permalink / raw) To: Zsh users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 8:22 ` Oliver Kiddle 2003-11-11 10:42 ` Peter Stephenson @ 2003-11-11 16:23 ` Danek Duvall 2003-11-11 19:06 ` Oliver Kiddle 1 sibling, 1 reply; 27+ messages in thread From: Danek Duvall @ 2003-11-11 16:23 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Jonas Juselius, zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 16:23 ` Danek Duvall @ 2003-11-11 19:06 ` Oliver Kiddle 2003-11-11 21:28 ` Danek Duvall 0 siblings, 1 reply; 27+ messages in thread From: Oliver Kiddle @ 2003-11-11 19:06 UTC (permalink / raw) To: Danek Duvall; +Cc: Jonas Juselius, zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 19:06 ` Oliver Kiddle @ 2003-11-11 21:28 ` Danek Duvall 2003-11-14 8:04 ` Oliver Kiddle 0 siblings, 1 reply; 27+ messages in thread From: Danek Duvall @ 2003-11-11 21:28 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Jonas Juselius, zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-11 21:28 ` Danek Duvall @ 2003-11-14 8:04 ` Oliver Kiddle 2003-11-14 10:47 ` Peter Stephenson 2003-11-14 15:46 ` Danek Duvall 0 siblings, 2 replies; 27+ messages in thread From: Oliver Kiddle @ 2003-11-14 8:04 UTC (permalink / raw) To: Danek Duvall; +Cc: Jonas Juselius, zsh-users 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 ________________________________________________________________________ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-14 8:04 ` Oliver Kiddle @ 2003-11-14 10:47 ` Peter Stephenson 2003-11-14 13:09 ` Oliver Kiddle 2003-11-14 15:46 ` Danek Duvall 1 sibling, 1 reply; 27+ messages in thread From: Peter Stephenson @ 2003-11-14 10:47 UTC (permalink / raw) To: zsh-users 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 ********************************************************************** ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-14 10:47 ` Peter Stephenson @ 2003-11-14 13:09 ` Oliver Kiddle 2003-11-14 16:12 ` Bart Schaefer 0 siblings, 1 reply; 27+ messages in thread From: Oliver Kiddle @ 2003-11-14 13:09 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-14 13:09 ` Oliver Kiddle @ 2003-11-14 16:12 ` Bart Schaefer 2003-11-14 16:23 ` Peter Stephenson 2003-11-14 17:01 ` Oliver Kiddle 0 siblings, 2 replies; 27+ messages in thread From: Bart Schaefer @ 2003-11-14 16:12 UTC (permalink / raw) To: Peter Stephenson, zsh-users, Oliver Kiddle 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-14 16:12 ` Bart Schaefer @ 2003-11-14 16:23 ` Peter Stephenson 2003-11-14 17:14 ` Bart Schaefer 2003-11-14 17:01 ` Oliver Kiddle 1 sibling, 1 reply; 27+ messages in thread From: Peter Stephenson @ 2003-11-14 16:23 UTC (permalink / raw) To: zsh-users 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 ********************************************************************** ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-14 16:23 ` Peter Stephenson @ 2003-11-14 17:14 ` Bart Schaefer 0 siblings, 0 replies; 27+ messages in thread From: Bart Schaefer @ 2003-11-14 17:14 UTC (permalink / raw) To: zsh-users [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" ) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-14 16:12 ` Bart Schaefer 2003-11-14 16:23 ` Peter Stephenson @ 2003-11-14 17:01 ` Oliver Kiddle 1 sibling, 0 replies; 27+ messages in thread From: Oliver Kiddle @ 2003-11-14 17:01 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-14 8:04 ` Oliver Kiddle 2003-11-14 10:47 ` Peter Stephenson @ 2003-11-14 15:46 ` Danek Duvall 2003-11-14 21:24 ` Danek Duvall 2003-11-17 15:47 ` Oliver Kiddle 1 sibling, 2 replies; 27+ messages in thread From: Danek Duvall @ 2003-11-14 15:46 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Jonas Juselius, zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-14 15:46 ` Danek Duvall @ 2003-11-14 21:24 ` Danek Duvall 2003-11-17 15:47 ` Oliver Kiddle 1 sibling, 0 replies; 27+ messages in thread From: Danek Duvall @ 2003-11-14 21:24 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Jonas Juselius, zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-14 15:46 ` Danek Duvall 2003-11-14 21:24 ` Danek Duvall @ 2003-11-17 15:47 ` Oliver Kiddle 2003-11-17 17:51 ` Danek Duvall 1 sibling, 1 reply; 27+ messages in thread From: Oliver Kiddle @ 2003-11-17 15:47 UTC (permalink / raw) To: Danek Duvall; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-17 15:47 ` Oliver Kiddle @ 2003-11-17 17:51 ` Danek Duvall 2003-11-19 10:23 ` Oliver Kiddle 0 siblings, 1 reply; 27+ messages in thread From: Danek Duvall @ 2003-11-17 17:51 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Completion function for bitkeeper? 2003-11-17 17:51 ` Danek Duvall @ 2003-11-19 10:23 ` Oliver Kiddle 0 siblings, 0 replies; 27+ messages in thread From: Oliver Kiddle @ 2003-11-19 10:23 UTC (permalink / raw) To: Danek Duvall; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2003-11-19 10:20 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-23 16:00 Completion function for bitkeeper? Steve Borho 2003-05-23 16:01 ` Danek Duvall 2003-11-06 15:32 ` Danek Duvall 2003-11-07 19:17 ` Oliver Kiddle 2003-11-10 18:20 ` Danek Duvall 2003-11-11 8:22 ` Oliver Kiddle 2003-11-11 10:42 ` Peter Stephenson 2003-11-11 15:21 ` Oliver Kiddle 2003-11-11 15:24 ` Peter Stephenson 2003-11-11 16:13 ` Oliver Kiddle 2003-11-11 16:23 ` Peter Stephenson 2003-11-11 16:44 ` Oliver Kiddle 2003-11-11 16:23 ` Danek Duvall 2003-11-11 19:06 ` Oliver Kiddle 2003-11-11 21:28 ` Danek Duvall 2003-11-14 8:04 ` Oliver Kiddle 2003-11-14 10:47 ` Peter Stephenson 2003-11-14 13:09 ` Oliver Kiddle 2003-11-14 16:12 ` Bart Schaefer 2003-11-14 16:23 ` Peter Stephenson 2003-11-14 17:14 ` Bart Schaefer 2003-11-14 17:01 ` Oliver Kiddle 2003-11-14 15:46 ` Danek Duvall 2003-11-14 21:24 ` Danek Duvall 2003-11-17 15:47 ` Oliver Kiddle 2003-11-17 17:51 ` Danek Duvall 2003-11-19 10:23 ` Oliver Kiddle
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).