RE: still confused about completion and matching

RE: still confused about completion and matching

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> ...
> 
> This condition predates styles. Now we do have suitable means for users to
> configure desired behaviour.

True.

> As I said long ago, I did not want Zsh to decide for me when to start menu
> completion if I did not request it. I do not want to invent another condition.
> 
> > As I sais in one of the previous mails, I wasn't completely happy with
> > that condition myself. The problem is that we certainly don't want to
> > insert the unambiguous string unconditionally even if insert-unambig
> > is set, because that string might often be empty.
> >
> 
> First, why are you _so_ sure there won't be any common prefix? For people that
> know shell glob patterns by heart it is sometimes easier to type pattern than
> to invent matching specification. And matches for foobar[1-9] are always
> shorter than pattern itself.

I'm not sure that it is, I'm sure that it might be...

> Second, how does it differ from ordinary completion? The sole thing I wanted -
> let's treat completion and matching equally. Both give you a set of matches to
> select from. Let's use common rules to decide when and how these matches are
> inserted. (After all, "ordinary" completion is just matching with pattern
> $PREFIX*$SUFFIX ... even if not implemented this way. I do not see why
> $PREFIX?#$SUFFIX should be treated differently :-)

... different from ordinary completion because there we have a lot of
code that can deal with the types of matching (match specs) allowed
there to build unambiguous strings without losing characters typed by
the user.

But I didn't want it to sound as if I'm religiously attached to the
current behaviour. I'm not. We can also change it to look up the
insert-unambiguous style lately, after the completions have been
generated. People can then use `zstyle -e' to add conditions if they
want.

I guess that would be acceptable to everyone? Especially if we add
a/some example(s) to the manual showing clever things one might want
to try there?

Bye
 Sven


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

Re: still confused about completion and matching

[E. Jay Berkenbilt]

I've been using zsh from the repository with the patches that enabled
my fancy glob completion behavior for a few weeks now and I have had
no problems with that or any other aspect of completion behavior.  I
get a little thrill every time I type a shell regexp and hit TAB
now. :-)  It seems that the changes have still not been committed to
the repository.  Is this because we're still waiting for reactions
from people who are not using the new patches or because we forgot or
for some other reason?  The part of me that is sending this message is
the part that monitors for unresolved issues and yearns for the day
when I can use an unpatched zsh. :-)

I still haven't had time to write my smbclient completion function.
I've also added rewriting _rcs to use _arguments to my "eventually"
list unless someone else gets to it first.  As brought up by another
user (Vincent Lefevre) the current behavior doesn't handle the more
subtle aspects of rcs's behavior very well.  I've run into this
several times myself either when looking at RCS directories that are
really on Windows machines or using rcs commands directly to cheat
while looking at CVS repositories.  I think I know rcs well enough to
(with the help of the rcs manual pages of course) rewrite _rcs....

                                Jay

PATCH: _rcs (was Re: still confused about completion and matching)

[Bart Schaefer]

On Nov 6, 10:34am, E. Jay Berkenbilt wrote:
} Subject: Re: still confused about completion and matching
} 
} It seems that the changes have still not been committed to the
} repository. Is this because we're still waiting for reactions from
} people who are not using the new patches or because we forgot or for
} some other reason?

I rather suspect it's just because Sven is busy.

} I still haven't had time to write my smbclient completion function.
} I've also added rewriting _rcs to use _arguments to my "eventually"
} list unless someone else gets to it first.  As brought up by another
} user (Vincent Lefevre) the current behavior doesn't handle the more
} subtle aspects of rcs's behavior very well.

Hrm, I was just looking at the current _rcs.  It begins:

    local nm=$compstate[nmatches] cmd="${words[1]:t}" ret=1

    if [[ $compstate[nmatches] -eq nm && -d RCS && $cmd != ci ]]; then

[[ $compstate[nmatches] -eq nm ]] can't possibly be false.  There used to
be a call to _files *before* that test, but it got moved to the end by
users/3472.

I played for a few minutes with ${${((s:/:)words[(r)-x*]:s/-x//}:-,v} but 
concluded I wasn't going to get it right in the time I have to spare.  So
consider that a hint towards your rewrite.

Index: Completion/User/_rcs
===================================================================
@@ -1,8 +1,8 @@
 #compdef co ci rcs

-local nm=$compstate[nmatches] cmd="${words[1]:t}" ret=1
+local cmd="${words[1]:t}" ret=1

-if [[ $compstate[nmatches] -eq nm && -d RCS && $cmd != ci ]]; then
+if [[ -d RCS && $cmd != ci ]]; then
   local rep expl

   rep=(RCS/*,v(:t:s/\,v//))


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net