* Re: PATCH: Completion/Cvs/
@ 1999-09-01 9:25 Sven Wischnowsky
1999-09-01 10:35 ` Tanaka Akira
0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 1999-09-01 9:25 UTC (permalink / raw)
To: zsh-workers
Tanaka Akira wrote:
> Also, I found a problem about _arguments.
>
> Z(2):akr@is27e1u11% ./Src/zsh -f
> is27e1u11% bindkey -e; fpath=($PWD/Completion/*(/)); autoload -U compinit; compinit -D; compdef _tst tst
> is27e1u11% compconf group_matches=yes
> is27e1u11% compconf message_format='%d'
> is27e1u11% compconf description_format='%d'
>
> is27e1u11% cvs login -e<TAB>
> ->
> is27e1u11% cvs login -evi
>
> is27e1u11% _tst () { _arguments '-e+:editor:(vi)' '*::mesg:false' }
> is27e1u11% tst a -e<TAB>
> ->
> is27e1u11% tst a -evi
>
> Becase _tst use '*::...', "vi" should not be completed.
I'm not so sure about this, so no patch for this now, but some
comments and questions.
In this example I think I would like to have it complete `vi' if the
cursor is directly after the `-e' (same word), because the `*::...'
should only take affect on whole words, i.e. in this case the word
after the `-e...'.
With that, this is just a special case of a more general problem with
completion after a `-e+:...' option. Currently we use the description
for the first option-argument to complete the next word after the `-e'
only if there really is nothing after the `-e' in the same word (so
that `foo -e <TAB>' completes the option-argument and `foo -ebar <TAB>'
completes normal arguments). But what if the empty string is a valid
option-argument? I think `-e+::...' should give us that (that's what
the patch below does).
So, is this ok? By changing your example to `-e::...' it would give
you what you want, I think (you could also use `-e-:...', btw). What
I'm really asking is if everyone thinks that the behavior with this
patch is what everyone would expect.
Or maybe I'm overlooking something here -- the patch is independent of
the way the `rest'-arguments are described.
Bye
Sven
diff -u oc/Base/_arguments Completion/Base/_arguments
--- oc/Base/_arguments Wed Sep 1 10:52:58 1999
+++ Completion/Base/_arguments Wed Sep 1 11:20:39 1999
@@ -464,9 +464,9 @@
# option, we skip over the first description only if there
# is something after the option name on the line.
- if [[ ( -z "$sopts" && "$ws[1]" != "$tmp[1]" ) ||
- ( -n "$sopts" && ( ( $tmp[1] = [-+]? && "$ws[1]" != "${tmp[1][1]}"${~soptseq}"${tmp[1][2]}" ) ||
- ( $tmp[1] != [-+]? && "$ws[1]" != "$tmp[1]" ) ) ) ]]; then
+ if [[ ( -z "$sopts" && ( "$def" = :* || "$ws[1]" != "$tmp[1]" ) ) ||
+ ( -n "$sopts" && ( ( $tmp[1] = [-+]? && ( "$def" = :* || "$ws[1]" != "${tmp[1][1]}"${~soptseq}"${tmp[1][2]}" ) ) ||
+ ( $tmp[1] != [-+]? && ( "$def" = :* || "$ws[1]" != "$tmp[1]" ) ) ) ) ]]; then
if [[ "$def" = [^*]*[^\\]:*[^\\]:* ]]; then
def="${def#?*[^\\]:*[^\\]:}"
optbeg="$beg"
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Completion/Cvs/
1999-09-01 9:25 PATCH: Completion/Cvs/ Sven Wischnowsky
@ 1999-09-01 10:35 ` Tanaka Akira
0 siblings, 0 replies; 6+ messages in thread
From: Tanaka Akira @ 1999-09-01 10:35 UTC (permalink / raw)
To: zsh-workers
In article <199909010925.LAA32701@beta.informatik.hu-berlin.de>,
Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> In this example I think I would like to have it complete `vi' if the
> cursor is directly after the `-e' (same word), because the `*::...'
> should only take affect on whole words, i.e. in this case the word
> after the `-e...'.
Why? Since a first non-option argument is the `a', I think the
`*::...' should take affect the `-e...' after the `a'.
I want to stop completion by _arguments until first non-option
argument --- the `a'. So In the example, I want the behaviour that
there should be no completion after the `a'.
> With that, this is just a special case of a more general problem with
> completion after a `-e+:...' option. Currently we use the description
> for the first option-argument to complete the next word after the `-e'
> only if there really is nothing after the `-e' in the same word (so
> that `foo -e <TAB>' completes the option-argument and `foo -ebar <TAB>'
> completes normal arguments). But what if the empty string is a valid
> option-argument? I think `-e+::...' should give us that (that's what
> the patch below does).
I think this is another issue.
Even if the empty string is a valid option-argument, getopt does not
take the option-argument from the same word because getopt never
knows it. In general, it is impossible to parse command line with the
rule that enable the empty string option-argument just after (without
white space) the option-argument word. So I think it is useless.
--
Tanaka Akira
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Completion/Cvs/
@ 1999-09-01 12:23 Sven Wischnowsky
0 siblings, 0 replies; 6+ messages in thread
From: Sven Wischnowsky @ 1999-09-01 12:23 UTC (permalink / raw)
To: zsh-workers
Tanaka Akira wrote:
> is27e1u11% bindkey -e; fpath=($PWD/Completion/*(/)); autoload -U compinit; compinit -D; compdef _tst tst
> is27e1u11% compconf group_matches=yes
> is27e1u11% compconf message_format='%d'
> is27e1u11% compconf description_format='%d'
> is27e1u11% _tst () { _arguments '-e+:editor:(vi)' '*::mesg:false' }
> is27e1u11% tst -e<TAB>
>
> This should complete `vi', but does not.
>
> is27e1u11% cvs <TAB>
> add commit export log release tag watchers
> admin diff history login remove unedit
> annotate edit import logout rtag update
> checkout editors init rdiff status watch
>
> Also, this should complete cvs common options addition to cvs commands.
Damn, I'm getting a bit confused...
> Reverting the hunk fix this problem. Is this correct?
No, that would make `tst a -e<TAB>' complete to `vi' again. The patch
below adds a flag that says if we left the command line parsing
because we found a non-option and we have `*::..'. Whew, I hope this
gets everything right this time ;-)
Bye
Sven
diff -u oc/Base/_arguments Completion/Base/_arguments
--- oc/Base/_arguments Wed Sep 1 13:04:49 1999
+++ Completion/Base/_arguments Wed Sep 1 14:19:38 1999
@@ -7,7 +7,7 @@
local args rest ws cur nth def nm expl descr action opt arg tmp
local single uns ret=1 soptseq soptseq1 sopts prefix line
-local beg optbeg argbeg nargbeg inopt fromrest
+local beg optbeg argbeg nargbeg inopt inrest fromrest
# Associative arrays used to collect information about the options.
@@ -500,7 +500,10 @@
line=( "$line[@]" "$ws[1]" )
[[ -n "$inopt" ]] && nargbeg=$(( beg - 1 ))
inopt=''
- [[ -z "$args[nth]" && "$rest" = \*::* ]] && break
+ if [[ -z "$args[nth]" && "$rest" = \*::* ]]; then
+ inrest=yes
+ break
+ fi
(( nth++ ))
fi
fi
@@ -537,7 +540,7 @@
optbeg="$nargbeg"
argbeg="$nargbeg"
fromrest=yes
- [[ "$def" = \*::* ]] && opt=''
+ [[ -n "$inrest" ]] && opt=''
fi
fi
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Completion/Cvs/
1999-09-01 11:03 Sven Wischnowsky
@ 1999-09-01 12:01 ` Tanaka Akira
0 siblings, 0 replies; 6+ messages in thread
From: Tanaka Akira @ 1999-09-01 12:01 UTC (permalink / raw)
To: zsh-workers
In article <199909011103.NAA00249@beta.informatik.hu-berlin.de>,
Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> The patch was mostly cosmetic, in fact. The question is: will users
> think that `-e+::..' does what they want in this case or not?
> Personally I don't care much if the patch is included or, since I
> would use `-e-:..' in such cases.
I think the behavior before 7596 is reasonable though I don't know
command that is fit to use it.
> @@ -535,6 +537,7 @@
> optbeg="$nargbeg"
> argbeg="$nargbeg"
> fromrest=yes
> + [[ "$def" = \*::* ]] && opt=''
> fi
> fi
>
Hm.
is27e1u11% bindkey -e; fpath=($PWD/Completion/*(/)); autoload -U compinit; compinit -D; compdef _tst tst
is27e1u11% compconf group_matches=yes
is27e1u11% compconf message_format='%d'
is27e1u11% compconf description_format='%d'
is27e1u11% _tst () { _arguments '-e+:editor:(vi)' '*::mesg:false' }
is27e1u11% tst -e<TAB>
This should complete `vi', but does not.
is27e1u11% cvs <TAB>
add commit export log release tag watchers
admin diff history login remove unedit
annotate edit import logout rtag update
checkout editors init rdiff status watch
Also, this should complete cvs common options addition to cvs commands.
Reverting the hunk fix this problem. Is this correct?
--
Tanaka Akira
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Completion/Cvs/
@ 1999-09-01 11:03 Sven Wischnowsky
1999-09-01 12:01 ` Tanaka Akira
0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 1999-09-01 11:03 UTC (permalink / raw)
To: zsh-workers
Tanaka Akira wrote:
> > In this example I think I would like to have it complete `vi' if the
> > cursor is directly after the `-e' (same word), because the `*::...'
> > should only take affect on whole words, i.e. in this case the word
> > after the `-e...'.
>
> Why? Since a first non-option argument is the `a', I think the
> `*::...' should take affect the `-e...' after the `a'.
>
> I want to stop completion by _arguments until first non-option
> argument --- the `a'. So In the example, I want the behaviour that
> there should be no completion after the `a'.
Ahem. Sorry, I simply overlooked the `a' in your previous mail. You
are right.
> > With that, this is just a special case of a more general problem with
> > completion after a `-e+:...' option. Currently we use the description
> > for the first option-argument to complete the next word after the `-e'
> > only if there really is nothing after the `-e' in the same word (so
> > that `foo -e <TAB>' completes the option-argument and `foo -ebar <TAB>'
> > completes normal arguments). But what if the empty string is a valid
> > option-argument? I think `-e+::...' should give us that (that's what
> > the patch below does).
>
> I think this is another issue.
>
> Even if the empty string is a valid option-argument, getopt does not
> take the option-argument from the same word because getopt never
> knows it. In general, it is impossible to parse command line with the
> rule that enable the empty string option-argument just after (without
> white space) the option-argument word. So I think it is useless.
The patch was mostly cosmetic, in fact. The question is: will users
think that `-e+::..' does what they want in this case or not?
Personally I don't care much if the patch is included or, since I
would use `-e-:..' in such cases.
Bye
Sven
diff -u oc/Base/_arguments Completion/Base/_arguments
--- oc/Base/_arguments Wed Sep 1 13:02:10 1999
+++ Completion/Base/_arguments Wed Sep 1 13:02:36 1999
@@ -525,6 +525,8 @@
# We either don't have a description for an argument of an option
# or we have a description for a optional argument.
+ opt=yes
+
if [[ -z "$def" ]]; then
# If we have none at all, use the one for this argument position.
@@ -535,6 +537,7 @@
optbeg="$nargbeg"
argbeg="$nargbeg"
fromrest=yes
+ [[ "$def" = \*::* ]] && opt=''
fi
fi
@@ -542,8 +545,7 @@
# be in a string that starts with an option name and continues with
# the first argument, test that (again, two loops).
- opt=yes
- if (( $#dopts )); then
+ if [[ -n "$opt" && $#dopts -ne 0 ]]; then
# Get the option names.
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* PATCH: Completion/Cvs/
@ 1999-08-31 15:03 Tanaka Akira
0 siblings, 0 replies; 6+ messages in thread
From: Tanaka Akira @ 1999-08-31 15:03 UTC (permalink / raw)
To: zsh-workers
This update cvs completion functions.
(1) Use "--opt=" instead of "--opt=-" when an argument for the option
is required.
(2) More cvs diff description.
Some long options such as "--context" has "optional_argument". I
used "--context=-" for the argument of _arguments. But it may better
to use another form that specify "=" as removal suffix.
Also, I found a problem about _arguments.
Z(2):akr@is27e1u11% ./Src/zsh -f
is27e1u11% bindkey -e; fpath=($PWD/Completion/*(/)); autoload -U compinit; compinit -D; compdef _tst tst
is27e1u11% compconf group_matches=yes
is27e1u11% compconf message_format='%d'
is27e1u11% compconf description_format='%d'
is27e1u11% cvs login -e<TAB>
->
is27e1u11% cvs login -evi
is27e1u11% _tst () { _arguments '-e+:editor:(vi)' '*::mesg:false' }
is27e1u11% tst a -e<TAB>
->
is27e1u11% tst a -evi
Becase _tst use '*::...', "vi" should not be completed.
Index: Completion/Cvs/_cvs
===================================================================
RCS file: /projects/zsh/zsh/Completion/Cvs/_cvs,v
retrieving revision 1.1.1.2
diff -u -F^( -r1.1.1.2 _cvs
--- _cvs 1999/08/27 12:05:29 1.1.1.2
+++ _cvs 1999/08/31 14:46:33
@@ -4,7 +4,7 @@
_arguments -s \
-{a,f,H,l,n,Q,q,r,t,v,w,x} \
'--version' '--help' '--help-commands' '--help-synonyms' '--help-options' \
- '--allow-root=-:rootdir:_files -/' \
+ '--allow-root=:rootdir:_files -/' \
'-b+:bindir:_cvs_bindir' \
'-T+:temporary directory:_cvs_tempdir' \
'-d+:cvsroot:_cvs_root' \
Index: Completion/Cvs/_cvs_diff
===================================================================
RCS file: /projects/zsh/zsh/Completion/Cvs/_cvs_diff,v
retrieving revision 1.1.1.1
diff -u -F^( -r1.1.1.1 _cvs_diff
--- _cvs_diff 1999/08/26 11:08:18 1.1.1.1
+++ _cvs_diff 1999/08/31 14:46:33
@@ -2,14 +2,46 @@
# "+abcdefhilnpstuw0123456789BHNRC:D:F:I:L:U:V:W:k:r:"
_arguments -s \
- -{a,b,c,d,e,f,h,i,l,n,p,s,t,u,w,0,1,2,3,4,5,6,7,8,9,B,H,N,R} \
- '-C:lines:' \
+ -{l,R} \
'-D+:date:_cvs_D' \
- '-F+:regex:' \
- '-I+:regex:' \
- '*-L+:label:' \
- '-U:lines:' \
- '-W:columns:' \
'-k+:keyword substitution:_cvs_k' \
'-r+:tag:_cvs_revisions' \
+ -{h,p,0,1,2,3,4,5,6,7,8,9} \
+ '--binary' \
+ '--brief' \
+ '--changed-group-format=:format:' \
+ '-c' '-C+:lines:' '--context=-:lines:' \
+ '-e' '--ed' \
+ '-t' '--expand-tabs' \
+ '-f' '--forward-ed' \
+ '--horizon-lines=:lines:' \
+ '--ifdef=:name:' \
+ '-w' '--ignore-all-space' \
+ '-B' '--ignore-blank-lines' \
+ '-i' '--ignore-case' \
+ '-I+:regex:' '--ignore-matching-lines=:regex:' \
+ '-b' '--ignore-space-change' \
+ '--initial-tab' \
+ '*-L+:label:' '*--label=:label:' \
+ '--left-column' \
+ '--line-format=:format:' \
+ '-d' '--minimal' \
+ '-N' '--new-file' \
+ '--new-group-format=:format:' \
+ '--new-line-format=:format:' \
+ '--old-group-format=:format:' \
+ '--old-line-format=:format:' \
+ '--paginate' \
+ '-n' '--rcs' \
+ '-s' '--report-identical-files' \
+ '--show-c-function' \
+ '-F+:regex:' '--show-function-line=:regex:' \
+ '-y' '--side-by-side' \
+ '-H' '--speed-large-files' \
+ '--suppress-common-lines' \
+ '-a' '--text' \
+ '--unchanged-group-format=:format:' \
+ '--unchanged-line-format=:format:' \
+ '-u' '-U+:lines:' '--unified=-:lines:' \
+ '-W:columns:' '--width=:columns:' \
'*:file:_cvs_diff_arg'
Index: Completion/Cvs/_cvs_history_x
===================================================================
RCS file: /projects/zsh/zsh/Completion/Cvs/_cvs_history_x,v
retrieving revision 1.1.1.2
diff -u -F^( -r1.1.1.2 _cvs_history_x
--- _cvs_history_x 1999/08/28 06:26:32 1.1.1.2
+++ _cvs_history_x 1999/08/31 14:46:33
@@ -1,7 +1,7 @@
#autoload
compset -P '*'
-# It should describe meaning.
+
compadd "$@" -y '(
F\ --\ release
O\ --\ checkout
--
Tanaka Akira
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-09-01 12:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-09-01 9:25 PATCH: Completion/Cvs/ Sven Wischnowsky
1999-09-01 10:35 ` Tanaka Akira
-- strict thread matches above, loose matches on Subject: below --
1999-09-01 12:23 Sven Wischnowsky
1999-09-01 11:03 Sven Wischnowsky
1999-09-01 12:01 ` Tanaka Akira
1999-08-31 15:03 Tanaka Akira
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).