Another slight weirdness

Another slight weirdness

[Peter Stephenson]

I've set the configuration:

  compconf completer=_complete
           correct_accept=2n \
           correct_prompt="Correcting (%e error[s]):"

so it's not actually supposed to be using correcton or approximation, and a
(not all that useful) directory containing

Xbarfoo2   Xfoo       Xnonofoo

and when I do

% echo foo<TAB>

(any letter of foo is enough, in fact, though I found out about this from
omitting the first character) I get offered all the files in the directory,
not just Xfoo.  Any ideas?  I think I've got all the patches (and if I
haven't, you'd better tell me about it :-)).  globcomplete is not set.  I
even get this with

_match_test () {
        (( compstate[matcher] <= 1 ))
}
_match_pattern () { }

and no `compctl -M'.


By the way, I never liked the way _setopt and _unsetopt reflected the
current state of the options, since usually I can't remember what's set and
the fact I don't get offered all possibilities just confuses me.  The fact
you now have to two $(...) calls on every single completion just to store
the current values --- this does not seem to be the sort of thing
completion should be doing by default --- makes me think even more strongly
that this is just not worth it for the basic set-up and anyone
sophisticated enough should add it themselves.  Furthermore, I get the same
list at the moment if I do `setopt ^D' or `unsetopt ^D' (that's what I
*want*, but it's not what should happen with the current functions).  Oh,
wait, I see why.  Except it still doesn't work properly because of all
those *@!@!#!** `no's when you run `unsetopt'.  That's probably a bug.

--- Completion/Core/_main_complete.uo	Tue Mar 23 15:59:51 1999
+++ Completion/Core/_main_complete	Tue Mar 23 16:21:31 1999
@@ -18,7 +18,7 @@
 local comp _set_options _unset_options
 
 _set_options=("${(@f)$({ unsetopt kshoptionprint; setopt } 2>/dev/null)}")
-_unset_options=("${(@f)$({ unsetopt kshoptionprint; setopt } 2>/dev/null)}")
+_unset_options=("${(@f)$({ unsetopt kshoptionprint; unsetopt } 2>/dev/null)}")
 
 setopt localoptions nullglob rcexpandparam
 unsetopt markdirs globsubst shwordsplit nounset ksharrays

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

RE: Another slight weirdness

[Andrej Borsenkow]

>
> By the way, I never liked the way _setopt and _unsetopt reflected the
> current state of the options, since usually I can't remember
> what's set and
> the fact I don't get offered all possibilities just confuses me.  The fact
> you now have to two $(...) calls on every single completion just to store
> the current values --- this does not seem to be the sort of thing
> completion should be doing by default --- makes me think even
> more strongly
> that this is just not worth it for the basic set-up and anyone
> sophisticated enough should add it themselves.

Anything more sophisticated will end up with just the same problem. O.K.,
what we have now:

 - top level shell has some options set
 - f1 is called - now we have global options and local f1 options
 - f2 is called from f1 - do we have three or two option sets now? That is,
if f1 has localoptions and changed some - will options upon exit from f2 be
restored to f1-local set or to global-set?

The latter smells like a bug. And if it is the former, that we have the
single global options set - and only need a way to acces it. And I really
suggest assoc array for that. That will make any work with options quite
easy (and actually un/setopt could be reduced to functions that simply set
array values :-)

Just tested - the options are restored to local f1 array. So, looks like it
is quite doable. And again, it will probably be quite useful outside of
completion as well.

cheers

/andrej

RE: Another slight weirdness

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> And I really
> suggest assoc array for that. That will make any work with options quite
> easy (and actually un/setopt could be reduced to functions that simply set
> array values :-)

Remember me saying that I kept being reminded of the old discussion
about replacing options with something more powerful when Bart
implemented the associative arrays?

This is exactly what I was thinking of. Some years ago we had a
discussion about something like this when we were slightly annoyed by
the fact that we can't give values for things like `ignoreeof' -- with 
an associative array this would be easy (although this would require
more changes than just adding an associative array as an interface to
the existing option code).

I'd prefer to keep `{un,}setopt' as builtins for the next couple of
official relases, at least (probably with a configure-option to get a
zsh without them).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Another slight weirdness

[Sven Wischnowsky]

Peter Stephenson wrote:

> I've set the configuration:
> 
>   compconf completer=_complete
>            correct_accept=2n \
>            correct_prompt="Correcting (%e error[s]):"
> 
> so it's not actually supposed to be using correcton or approximation, and a
> (not all that useful) directory containing
> 
> Xbarfoo2   Xfoo       Xnonofoo
> 
> and when I do
> 
> % echo foo<TAB>
> 
> (any letter of foo is enough, in fact, though I found out about this from
> omitting the first character) I get offered all the files in the directory,
> not just Xfoo.  Any ideas?  I think I've got all the patches (and if I
> haven't, you'd better tell me about it :-)).  globcomplete is not set.  I
> even get this with

This clearly shows that you have all the patches... it's that test
again. This time I've made it very explicit.

> By the way, I never liked the way _setopt and _unsetopt reflected the
> current state of the options, since usually I can't remember what's set and
> the fact I don't get offered all possibilities just confuses me.  The fact
> you now have to two $(...) calls on every single completion just to store
> the current values --- this does not seem to be the sort of thing
> completion should be doing by default --- makes me think even more strongly
> that this is just not worth it for the basic set-up and anyone
> sophisticated enough should add it themselves.  Furthermore, I get the same
> list at the moment if I do `setopt ^D' or `unsetopt ^D' (that's what I
> *want*, but it's not what should happen with the current functions).  Oh,
> wait, I see why.  Except it still doesn't work properly because of all
> those *@!@!#!** `no's when you run `unsetopt'.  That's probably a bug.

1) Oops, programming by M-w (ahem).
2) Like you I always have problems remembering which options I've set.
3) I did it this way when I first re-implemented some of the old
   example-compctls, there it is done this way.
4) But then, these examples were implemented at a time where we didn't 
   have these `no's prepended to every second option name.
5) I always wondered: is there anybody who actually likes this? Or
   should we implement something like `allopts' in C-code?

So, I wouldn't mind to change the examples to normally use only
`_options' (or even `compgen -o'), leave the other functions, comment
out the stuff in `_main_complete' and add comments to `_{un,}setopt'.

Bye
 Sven

diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Tue Mar 23 16:14:06 1999
+++ Completion/Core/_path_files	Tue Mar 23 17:02:22 1999
@@ -424,8 +424,11 @@
   suffixes=( $str$^pats )
   suffixes=( "${(@)suffixes:gs.**.*.}" )
   tmp2=( ${~tmp1}${~matchflags}${~suffixes} )
-  tmp2=("${(@M)tmp2:#*$~patlast}")
-
+  if [[ "$tmp1" = */* && "$patlast" != \*/* ]]; then
+    tmp2=("${(@M)tmp2:#*${~patlast}}")
+  else
+    tmp2=("${(@M)tmp2:#$~patlast}")
+  fi
   if [[ $#tmp2 -eq 0 ]]; then
     # No match, insert the expanded path and add the original tail.
 

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de