* Fun with new completion
@ 1999-03-23 13:42 Andrej Borsenkow
0 siblings, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 1999-03-23 13:42 UTC (permalink / raw)
To: ZSH workers mailing list
bor@itsrm2:~%> vared pat
pat path
In other words, vared tried to complete the name of local variable, that is
defined in completion function :-) pat is not defined otherwise.
And it just occured to me, that the same could happen in e.g. [un]setopt. As
I understand, they do it by listing currently set/unset options ... with the
result, that if options are changed in some top level function, they will
list wrong options ...
/andrej
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Fun with new completion
1999-03-23 13:59 Sven Wischnowsky
@ 1999-03-23 14:17 ` Andrej Borsenkow
0 siblings, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 1999-03-23 14:17 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
>
> Maybe we should rename the local parameters (where needed) to `_...',
> modify the function `_vars' to show only parameters without a leading
> underscore and be callable from everywhere.
I would not rely on names (it is good as convention - but imagine bug
reports "ZSH does not complete my variables" :-)
What about adding GLOBAL flag to variables and option to list only
global/local ones? Sounds nice (and may be useful in other contexts as well)
cheers
/andrej
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fun with new completion
@ 1999-03-23 13:59 Sven Wischnowsky
1999-03-23 14:17 ` Andrej Borsenkow
0 siblings, 1 reply; 5+ messages in thread
From: Sven Wischnowsky @ 1999-03-23 13:59 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> bor@itsrm2:~%> vared pat
> pat path
>
> In other words, vared tried to complete the name of local variable, that is
> defined in completion function :-) pat is not defined otherwise.
>
> And it just occured to me, that the same could happen in e.g. [un]setopt. As
> I understand, they do it by listing currently set/unset options ... with the
> result, that if options are changed in some top level function, they will
> list wrong options ...
I was aware of the problem with parameter names, but hadn't thought
about the options.
Maybe we should rename the local parameters (where needed) to `_...',
modify the function `_vars' to show only parameters without a leading
underscore and be callable from everywhere.
For the options I can only see the solution to make `_main_complete'
save the original set and unset options in arrays and then add two
functions to complete from these arrays (this is currently only used
for `setopt' and `unsetopt', but to make this cleanly...).
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fun with new completion
@ 1999-03-09 14:50 Sven Wischnowsky
0 siblings, 0 replies; 5+ messages in thread
From: Sven Wischnowsky @ 1999-03-09 14:50 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> I have /archive/pub/unix/sudo/ with cu-sudo* files in it. I forgot, that
> they are prefixed with cu- and did
>
> gzcat /a/p/u/s/s<TAB>
>
> with the nice result
>
> gzcat //a
>
> Plain old multicomp just beeps and leaves the string as is. Now, it is
> _really_ hard to decide what to do ... Should it complete as far as
> possible? Or, if nothing matches, leave command line as is? Again, the
> problem is, zsh cannot read your mind and decide, where was the error.
At least it shouldn't give what it gives now... this was something
that looked good for the things I tried it with but sometimes...
The patch below makes it leave the line unchanged. A probably better
solution would have a second loop over the `-W' paths to try to expand
as much of the path as possible. Hm, I /think/ that would be better...
Bye
Sven
P.S.: The senders in the summary of my mail reader look like a party
of ping-pong between Andrej and me...
diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files Tue Mar 9 15:31:15 1999
+++ Completion/Core/_path_files Tue Mar 9 15:46:06 1999
@@ -261,9 +261,6 @@
# next `-W' path.
if [[ $#collect -eq 0 ]]; then
- compadd -QU "$addpfx[@]" "$addsfx[@]" "$group[@]" "$expl[@]" \
- -i "$IPREFIX" -p "${linepath:q}${testpath:q}" -S "/${ostr#*/}" \
- -W "$tmp1" -f "$ignore[@]" - "${(@)tmp1:q}"
continue 2
elif [[ $#collect -ne 1 ]]; then
# If we have more than one possible match, this means that the
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Fun with new completion
@ 1999-03-09 14:23 Andrej Borsenkow
0 siblings, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 1999-03-09 14:23 UTC (permalink / raw)
To: ZSH workers mailing list
I have /archive/pub/unix/sudo/ with cu-sudo* files in it. I forgot, that
they are prefixed with cu- and did
gzcat /a/p/u/s/s<TAB>
with the nice result
gzcat //a
Plain old multicomp just beeps and leaves the string as is. Now, it is
_really_ hard to decide what to do ... Should it complete as far as
possible? Or, if nothing matches, leave command line as is? Again, the
problem is, zsh cannot read your mind and decide, where was the error.
cheers
/andrej
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-03-23 14:19 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-23 13:42 Fun with new completion Andrej Borsenkow
-- strict thread matches above, loose matches on Subject: below --
1999-03-23 13:59 Sven Wischnowsky
1999-03-23 14:17 ` Andrej Borsenkow
1999-03-09 14:50 Sven Wischnowsky
1999-03-09 14:23 Andrej Borsenkow
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).