completion with globbing, take 2

completion with globbing, take 2

[E. Jay Berkenbilt]

Several days ago, I wanted to know how I could get zsh to respond to 

something *TAB

by replacing the * with the list everything that the completion system
would return instead of everything * would match in the current
directory.  I was told to do this:

zstyle ':completion:*' completer _oldlist _complete _match
bindkey "^I" complete-word

I've spent a lot of time trying to figure this out, but this still
doesn't work and I don't know how to make it work.  This gives a
behavior like menu-complete.  I never want menu-complete-like
functionality.  I want behavior more like what expand-or-complete does
except that I want only what the completion system would return to be
substituted.

I will be very explicit to reduce the chance of my question being
misunderstood.

zsh -f

> zsh% autoload -U compinit
> zsh% compinit
> zsh% mkdir /tmp/z
> zsh% cd /tmp/z
> zsh% mkdir 1 2 3
> zsh% touch a b c

Type:

> zsh% rmdir TAB

You see:

> zsh% rmdir 
> 1/  2/  3/

Type:

> zsh% rmdir *TAB

You see:

> zsh% rmdir 1 2 3 a b c 

Now configure as above:

> zsh% zstyle ':completion:*' completer _oldlist _complete _match
> zsh% bindkey "^I" complete-word

Type:

> zsh% rmdir *TAB

You see:

> zsh% rmdir 1/
1/  2/  3/

Each subsequent TAB rotates between 1/, 2/, and 3/.

What I want:

> zsh% rmdir *TAB

should yield

> zsh% rmdir 1 2 3 

Is there a way to do this?

--
E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/

Re: completion with globbing, take 2

[Bart Schaefer]

On Sep 17,  1:50pm, E. Jay Berkenbilt wrote:
}
} Several days ago, I wanted to know how I could get zsh to respond to 
} 
} something *TAB
} 
} by replacing the * with the list everything that the completion system
} would return instead of everything * would match in the current
} directory.  I was told to do this:
} 
} zstyle ':completion:*' completer _oldlist _complete _match
} bindkey "^I" complete-word

More precisely, you were told that Andrej does that.

Andrej probably wasn't expecting you to use it verbatim, though, because
he didn't show you what his settings for the matcher-list style are.  You
didn't say whether you have any settings for matcher-list; if you don't,
the _match completer won't do anything.

} I want behavior more like what expand-or-complete does except that I
} want only what the completion system would return to be substituted.

That's what the _expand completer is for.  I believe you want:

zstyle ':completion:*' completer _oldlist _expand _complete _match
zstyle ':completion::expand:*' completions true

And maybe you don't even need the _match on the end, if you haven't
worked out any matcher-list values yet.  The _match completer is for
doing things like case-insensitive completion and completion of sub-
parts of file names (e.g., completing on both sides of a ".").

You probably also want to read about the following styles:

    accept-exact
    add-space
    completions
    glob
    keep-prefix
    sort
    subst-globs-only
    substitute
    suffix

-- 
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   

Re: completion with globbing, take 2

[E. Jay Berkenbilt]

Okay, with everyone's help, my problem is solved, but the solution
brings up lots of questions.


>   } Several days ago, I wanted to know how I could get zsh to respond to 
>   } 
>   } something *TAB
>   } 
>   } by replacing the * with the list everything that the completion system
>   } would return instead of everything * would match in the current
>   } directory.  I was told to do this:
>   } 
>   } zstyle ':completion:*' completer _oldlist _complete _match
>   } bindkey "^I" complete-word
>
>   More precisely, you were told that Andrej does that.
>
>   Andrej probably wasn't expecting you to use it verbatim, though, because
>   he didn't show you what his settings for the matcher-list style are.  

Right.

>   You
>   didn't say whether you have any settings for matcher-list; if you don't,
>   the _match completer won't do anything.

Sorry -- my original message failed to say that I was starting with
zsh -f with only the completion system loaded and no additional
customization.  This is why I was much more explicit in my second
message.

Also, after reading the code, I don't believe it is true that _match
won't do anything without matcher-list set -- see analysis and
questions below.

>   } I want behavior more like what expand-or-complete does except that I
>   } want only what the completion system would return to be substituted.
>
>   That's what the _expand completer is for.  I believe you want:
>
>   zstyle ':completion:*' completer _oldlist _expand _complete _match
>   zstyle ':completion::expand:*' completions true

This almost worked, and it gave me enough additional information to
get the rest of the way there.  I now have the following:

  zstyle ':completion:*' completer _oldlist _complete _expand _match
  zstyle ':completion::expand:*' completions true
  bindkey "^I" complete-word

This seems to do exactly what I'm looking for.  We'll see whether I've
broken anything.

Removing any of _complete, _expand, or _match or changing the order in
which they appear breaks things.

Now I've analyzed the code and think I understand why this works, but
I'm not 100% certain.  Interestingly, ^X? doesn't work when I do

rmdir *^X?

but that's okay -- I just did setopt xtrace and then

rmdir *TAB

Again, I have just 1, 2, 3, a, b, and c in the currently directory
where 1, 2, and 3 are directories and a, b, and c are files.

Looking at the trace and the code, here's what I think is happening:

_main_complete is called.  It looks up my completers (_oldlist,
_complete, _expand, and _match) and calls then in order.  _oldlist
returns nothing, _complete returns nothing (since no files start with
'*').  Now it starts getting interesting.  _expand is called.  Since I
have set the completions style for expand to true, it sets
compstate[insert]=all which gives me the behavior I'm looking for with
respect to the replacement.  However, since the current context is not
expand-word:*, it does not call _complete and thus just returns 1.
Finally, _match is called.  I don't follow exactly what's going on at
the top of _match, but it doesn't matter.  Since I don't have
match-original set, _match sets compstate[pattern_match]='*' and calls
_complete again.  This time, since compstate[pattern_match] is set,
_complete actually does find matches.

So the right thing happens, but the path to the desired end seems
quite convoluted and counterintuitive to me.  I would never have
figured this out without the significant hints without having to spend
a lot of time grokking this code.

So there end up being two important commands here.  Without this one:

  zstyle ':completion::expand:*' completions true

the call to _expand doesn't set compstate[insert]=all.  Now if I look
at this:

  zstyle ':completion:*' completer _oldlist _complete _expand _match

If we remove _match, then _complete never gets called again with
compstate[pattern_match]='*', so it is essential.  If _expand appears
before _complete, then 

rmdir TAB

by itself inserts all the matches.

So, in summary, it seems that the only thing I'm using expand for is
to get compstate[insert]=all.  The only thing I'm using _match for is
to get _complete to be called with with compstate[pattern_match]='*'.
I can't do this with setopt glob_complete because if I do, then the
first call to _complete will generate matches when it is called before
the call to _expand, so I'll get the menu behavior instead of what I
wanted.  If I put _expand before _complete with these settings, I
always get all matches substituted (as if I had typed the *), which
renders the completion system pretty useless.

So, is my analysis correct?  Am I getting behavior that was intended
here, or have I just stumbled upon a way to do this?  I feel like I'm
getting the desired behavior through a series of coincidences and that
this could change or break pretty easily in the future....

Thanks for all the help.

                                Jay

completion and globbing, part 2

[E. Jay Berkenbilt]

It occurred to me that if the analysis in my last message was true,
the following would work:

zstyle ':completion:*' completer _oldlist _complete _qcomp _ignored
bindkey "^I" complete-word

where _qcomp is defined as follows:

   #autoload

   compstate[pattern_match]='*'
   compstate[insert]=all
   ret=1
   _complete && ret=0
   return ret

This does, in fact, give me exactly the behavior I'm looking for
without using _expand or _match.

(I also added _ignored, but that doesn't have anything to do with
this.)

--
E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/

RE: completion and globbing, part 2

[Andrej Borsenkow]

>
>
> It occurred to me that if the analysis in my last message was true,
> the following would work:
>
> zstyle ':completion:*' completer _oldlist _complete _qcomp _ignored
> bindkey "^I" complete-word
>
> where _qcomp is defined as follows:
>
>    #autoload
>
>    compstate[pattern_match]='*'
>    compstate[insert]=all
>    ret=1
>    _complete && ret=0
>    return ret
>
> This does, in fact, give me exactly the behavior I'm looking for
> without using _expand or _match.
>
> (I also added _ignored, but that doesn't have anything to do with
> this.)
>


In this case, you, probably, do not need _oldlist either.

Well, what you've effectively done is to write stripped-down version of _match
:-) Could you consider patching _match adding a style to control it? But,
really, it may not be as simple. _expand gives you choice to select all
expantions as a tag. But _match just modifies behaviour of subsequent
completer ... I mean, general implementation should give a choice to insert or
not to insert all matching completions. I currently do not see place to put it
in.

May be, widget to do it (insert all current choices) would be the simplest
case. Hmm ... may be it is even possible to implement it as function.

-andrej

insert-all-matches example RE: completion and globbing, part 2

[Andrej Borsenkow]

>
> May be, widget to do it (insert all current choices) would be the simplest
> case. Hmm ... may be it is even possible to implement it as function.
>

Very dumb implemetation. It won't work (correctly) if anything is already
inserted on command line - that is, it will insert all matches directly after
anything already there. This may or may not be appropriate.

bor@itsrm2% which _insert_all_matches
_insert_all_matches () {
        compstate[insert]=all
        compstate[old_list]=keep
        _complete
}
bor@itsrm2% zle -C insert-all-matches complete-word _insert_all_matches
bor@itsrm2% bindkey '^Xi' insert-all-matches

With these you could do:

bor@itsrm2% ls f*^D
bor@itsrm2% ls f*
Completing file
fnt/    foo.c

Now press ^Xi

bor@itsrm2% ls fnt foo.c

But, as stated, it has all sorts of problems. It does not work correctly after
*completion* - it tries to complete word already inserted (that is, it is
treated as new completion instead of continuation of old - but this may be
related to my styles settings).  ^D is needed to get a list that is inserted
with ^Xi.

-andrej

Re: completion with globbing, take 2

[Bart Schaefer]

On Sep 17,  7:03pm, E. Jay Berkenbilt wrote:
}
} Also, after reading the code, I don't believe it is true that _match
} won't do anything without matcher-list set -- see analysis and
} questions below.

Right, I was confused, as Andrej has already pointed out.  (The completion
system has a tendency to do that to almost anyone from time to time, even
Sven.)
 
} Now I've analyzed the code and think I understand why this works, but
} I'm not 100% certain.  Interestingly, ^X? doesn't work when I do
} 
} rmdir *^X?

I believe _complete_debug actually did work, but _message did not (and
therefore you didn't see the "Trace output left in ..." message).  If
you try it again and then immediately hit C-p (up-line-or-history), you
should find that the command to view the trace file has in fact been
recorded.

}   zstyle ':completion:*' completer _oldlist _complete _expand _match
} 
} If we remove _match, then _complete never gets called again with
} compstate[pattern_match]='*', so it is essential.  If _expand appears
} before _complete, then 
} 
} rmdir TAB
} 
} by itself inserts all the matches.

Yes, I was a bit surprised by that myself -- I think it must be a bug.
I don't think the _expand completer should do anything when there's no
prefix nor a suffix.

On Sep 17,  8:17pm, E. Jay Berkenbilt wrote:
} Subject: completion and globbing, part 2
}
} It occurred to me that if the analysis in my last message was true,
} the following would work:
[...]
} This does, in fact, give me exactly the behavior I'm looking for
} without using _expand or _match.

Does it?  What happens when you complete a pattern that matches only
directories?  (I get, it inserts all the directories and adds a slash
after only the last one, so if I press TAB again I get completions in
that last directory, which seems unlikely to be what you'd want.)

Incidentally, the three lines

   ret=1
   _complete && ret=0
   return ret

are equivalent to just

   _complete
   return

and if _complete is the last line in the function, you don't even need
the `return'.

On Sep 18, 10:07am, Andrej Borsenkow wrote:
} Subject: RE: completion with globbing, take 2
}
} [...] consider something like
} 
} setopt *complete*TAB
} 
} WIth _match this enters menu completion - but _expand_word (I tried
} it) gives you nothing. So, there seems to be no way to just insert all
} matching choices.

As Jay discerned, `compstate[pattern_match]=\*' is all you need to get
the same effect as _match in this case.  The only additional stuff that
_match gets you (now that I'm thinking correctly about what it does) is
handling of the match-original and insert-unambiguous styles.

} While _expand (and friends) may be useful at times, _match just seems to be
} more powerful. (Of course, another general solution is to have widget that
} would insert all listed choices at once. Was not it discussed once?)

Only in the context of _expand, I think, which led to the all-expansions
tag.  The default behavior of _expand is to insert all the expansions and
then enter menu completion (with all the expansions being the first item
in the menu) so you can cycle away to just some of them if you prefer.

On Sep 18, 10:53am, Andrej Borsenkow wrote:
} Subject: RE: completion and globbing, part 2
}
} Well, what you've effectively done is to write stripped-down version of
} _match :-)

Not quite; he's written a stripped-down version of "_expand with the
completions style defaulted to true, followed by _match".

} Could you consider patching _match adding a style to control it?

The most obvious thing would be to have _match itself recognize the
completions style.

} But _match just modifies behaviour of subsequent completer ...

Eh?  It *calls* _complete.  How is that modifying subsequent completers?

On Sep 18,  1:59pm, Andrej Borsenkow wrote:
} Subject: insert-all-matches example RE: completion and globbing, part 2
}
} _insert_all_matches () {
}         compstate[insert]=all
}         compstate[old_list]=keep
}         _complete
} }
} bor@itsrm2% zle -C insert-all-matches complete-word _insert_all_matches
} bor@itsrm2% bindkey '^Xi' insert-all-matches

I get:

_files:54: no matches found: *:all-files

You have to remember to provide the standard completion-system setopts
in any wrapper around the supplied completer functions.

 _insert_all_matches () {
     setopt localoptions nullglob rcexpandparam extendedglob noshglob
     unsetopt markdirs globsubst shwordsplit nounset ksharrays
     compstate[insert]=all
     compstate[old_list]=keep
     _complete
 }

(Speaking of which, there's nullglob in the list.  Who was it who added
(N) to all those glob patterns in several functions?)

} But, as stated, it has all sorts of problems. It does not work correctly after
} *completion* - it tries to complete word already inserted (that is, it is
} treated as new completion instead of continuation of old - but this may be
} related to my styles settings).

Hmm ... can you give an example of what you see that you think is wrong?
It seems OK to me (and I'm curious which of your styles might botch it).

-- 
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   

RE: completion with globbing, take 2

[Andrej Borsenkow]

>
> On Sep 18, 10:53am, Andrej Borsenkow wrote:
> } Subject: RE: completion and globbing, part 2
> }
> } Well, what you've effectively done is to write stripped-down version of
> } _match :-)
>
> Not quite; he's written a stripped-down version of "_expand with the
> completions style defaulted to true, followed by _match".
>

I tentatively disagree. The main difference between _expand and _match is who
generates matches. Completion aside, _expand generates "matches" (that are
actually expansions in this case) itself. _match takes all possible
completions and tries to match them against given pattern. See the difference?
To write stripped-down version of _expand means something like (for globbing
only)

foo=($~CURRENT)
compadd -- "$foo"

As I wrote, it is just a coincidence that file completion is using the same
pattern from command line, hence _expand and _match look alike.

BTW thank you all for finally making it clear to me :-)))

> } Could you consider patching _match adding a style to control it?
>
> The most obvious thing would be to have _match itself recognize the
> completions style.
>

Is is not enough. See later.

> } But _match just modifies behaviour of subsequent completer ...
>
> Eh?  It *calls* _complete.  How is that modifying subsequent completers?
>

Eh ... I meant that, actually. I had in mind this difference between _expand
and _match as described above.

>
> You have to remember to provide the standard completion-system setopts
> in any wrapper around the supplied completer functions.
>
>  _insert_all_matches () {
>      setopt localoptions nullglob rcexpandparam extendedglob noshglob
>      unsetopt markdirs globsubst shwordsplit nounset ksharrays
>      compstate[insert]=all
>      compstate[old_list]=keep
>      _complete
>  }
>
> (Speaking of which, there's nullglob in the list.  Who was it who added
> (N) to all those glob patterns in several functions?)
>

Sven in zsh-workers/12768

> } But, as stated, it has all sorts of problems. It does not work
> correctly after
> } *completion* - it tries to complete word already inserted (that is, it is
> } treated as new completion instead of continuation of old - but this may be
> } related to my styles settings).
>
> Hmm ... can you give an example of what you see that you think is wrong?
> It seems OK to me (and I'm curious which of your styles might botch it).
>

I had in mind interaction between _oldlist and _match. When you have a pattern
and press TAB first time, you get a list. When you press TAB second time,
completion system tries to reuse this old list instead of taking current word
and trying to complete it (assuming proper style setup - but, may be, it is
even default). So, somehow I expected currently inserted word to be replaced
with all matching completions (and compstate[oldlist]=keep was exactly for
that). But I am not even sure, if it possible.

O.K. about adding completions style to _match. Note, that if completions style
is set for _expand it just calls _complete. If it generated any matches,
_expand just exits. If no matches were generated, it does it itself and now
has full control over possible tags.

But what we actually need, is to get completions that _complete just
generated, together with all tags, descriptions and whatever else, and add to
them e.g. "all matches" tag. And that while preserving all user settings for
verbose, tag ordering etc etc etc. Something like

compstate[pattern_match]=\*
  if _complete; then
     if _requested all-matches ...
     then
        all_matches=??? # gets all generated matches
        compadd ... -- "$all_matches"
     fi
   fi

Hmm ... actually, quite possible. Assuming, that we can get all matches.

-andrej

Re: completion with globbing, take 2

[Bart Schaefer]

On Sep 18, 10:08pm, Andrej Borsenkow wrote:
} Subject: RE: completion with globbing, take 2
}
} > Not quite; he's written a stripped-down version of "_expand with the
} > completions style defaulted to true, followed by _match".
} 
} I tentatively disagree. The main difference between _expand and
} _match is who generates matches. Completion aside, _expand generates
} "matches" (that are actually expansions in this case) itself.

Not when the completions style is set.  Then it assigns compstate[insert]
and returns, leaving it to the following completers to generate matches.

} _match takes all possible completions and tries to match them against
} given pattern. See the difference?

Yes, but ... _match doesn't "take" anything; it, too, calls _complete,
maybe more than once, with different values of compstate[pattern_match].

Try this in zsh -f:

zstyle ':completion:*' completer _expand _match
zstyle ':completion:*' completions true
autoload -U compinit ; compinit -D

and then look at a trace from ^X?.  The only interesting things that
happen before _complete is called are assignments to compstate[insert]
and compstate[pattern_match], exactly as in Jay's little function.

} To write stripped-down version of _expand means [...]

I didn't say "stripped-down version of _expand", I said "stripped-down
version of _expand with the completions style defaulted to true", which
takes a completely different code branch.

} As I wrote, it is just a coincidence that file completion is using the same
} pattern from command line, hence _expand and _match look alike.

I'd mostly agree with you if _match were replaced by _complete in the
style above.

} BTW thank you all for finally making it clear to me :-)))

It's getting a lot clearer to me, too ...
 
} > The most obvious thing would be to have _match itself recognize the
} > completions style.
} 
} Is is not enough. See later.

Not enough for what?

} O.K. about adding completions style to _match. Note, that if
} completions style is set for _expand it just calls _complete.

No.  If the completions style is set for _expand it doesn't call anything.
It only calls _complete in the expand-word:* context; we're talking about
the :completion:* context.

} If no matches were generated, it does it itself and now has full
} control over possible tags.

No, it always returns without doing anything itself when the completions
style is set.  expand-word:* just determines whether it returns success,
otherwise it always returns failure.

} But what we actually need, is to get completions that _complete just
} generated

No, we just need to call complete and let it generate things, just like
_match always does.  We just have to tell _complete to insert everything
that it generates.  Try the following patch with

zstyle ':completion:*' completer _match
zstyle ':completion:*' completions true
bindkey '\t' complete-word

(Arguably "completions" is not the best name for this style as it's used
here, but for purposes of example ...)

Index: Completion/Core/_match
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Completion/Core/_match,v
retrieving revision 1.14
diff -c -r1.14 _match
--- Completion/Core/_match	2000/04/11 15:07:44	1.14
+++ Completion/Core/_match	2000/09/19 01:58:57
@@ -20,6 +20,7 @@
 
 zstyle -s ":completion:${curcontext}:" match-original orig
 zstyle -b ":completion:${curcontext}:" insert-unambiguous ins
+zstyle -t ":completion:${curcontext}:" completions && compstate[insert]=all
 
 # Try completion without inserting a `*'?
 


-- 
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   

RE: completion with globbing, take 2

[Andrej Borsenkow]

> } > The most obvious thing would be to have _match itself recognize the
> } > completions style.
> }
> } Is is not enough. See later.
>
> Not enough for what?
>

I must apologize. For some reason I had impression, that _expand offers all
possible *completions* in addition to expansions. What led me to it was

     There is another style, completions, which allows _expand to
     display or insert all _completions_ generated for the string.  The
     use of this is that the tags expansions and all-expansions are
     available, unlike with _complete.

Actually, you can either insert all completions (without possibility to menu
select AND without doing full completion - it is using only _complete so
matching won't work) *or* choose from the expansions. Docs could be more clear
on this point.

-andrej

Re: completion with globbing, take 2

[Bart Schaefer]

On Sep 20,  7:06pm, Andrej Borsenkow wrote:
} Subject: RE: completion with globbing, take 2
}
} I must apologize. For some reason I had impression, that _expand offers all
} possible *completions* in addition to expansions.

There's a possibly-unwarranted assumption that the completions will
include the interesting subset of all expansions, so you wouldn't want
the rest of the expansions as well.

} it is using only _complete so matching won't work

Once again, that's true only if you're using the _expand_word binding.
Matching works fine if you're using complete-word and you have _match
somewhere after _expand in the completer style.

} Actually, you can either insert all completions (without possibility
} to menu select [...]) *or* choose from the expansions. Docs could be
} more clear on this point.

Yes, I'll send a patch separately to zsh-workers.  However, it does say:

completions
     This style is used by the _expand completer function. If it is set
     to `true', the completer will not generate expansions, but instead
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     the completions will be generated as normal and all of them will be
     inserted into the command line.


-- 
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   

Re: completion with globbing, take 2

[E. Jay Berkenbilt]

>   } Also, after reading the code, I don't believe it is true that _match
>   } won't do anything without matcher-list set -- see analysis and
>   } questions below.
>
>   Right, I was confused, as Andrej has already pointed out.  (The completion
>   system has a tendency to do that to almost anyone from time to time, even
>   Sven.)

Actually, I'll admit to being heartened to see others getting confused
about this.  It is pretty confusing. :-)

>   On Sep 17,  8:17pm, E. Jay Berkenbilt wrote:
>   } Subject: completion and globbing, part 2
>   }
>   } It occurred to me that if the analysis in my last message was true,
>   } the following would work:
>   [...]
>   } This does, in fact, give me exactly the behavior I'm looking for
>   } without using _expand or _match.
>
>   Does it?  What happens when you complete a pattern that matches only
>   directories?  (I get, it inserts all the directories and adds a slash
>   after only the last one, so if I press TAB again I get completions in
>   that last directory, which seems unlikely to be what you'd want.)

Well, in fact, I never do this with rmdir.  I chose it as an example
only because it's easy to work with and has simple completion
functions.  I really use this with cvs add and cvs rm where it is
great.  If I create a bunch of test files, I can do cvs add *TAB and
automatically not get the files that are already registered or files
that are in .cvsignore.  A great timesaver.  What I used to do is 
cvs add `cvs -qn update | fgrep '?' | awk '{print $2}'` (or something
like that) which isn't tooo bad but is obviously not as nice as cvs
add *TAB. :-)

>   Incidentally, the three lines
>
>      ret=1
>      _complete && ret=0
>      return ret
>
>   are equivalent to just
>
>      _complete
>      return
>
>   and if _complete is the last line in the function, you don't even need
>   the `return'.

Nice to know.  So I guess zsh functions are like lisp and perl -- the
value of the last statement is the return value -- but with the
additional feature that return with no arguments returns the last
value.... I'll have to play a bit to see what the real rules are or
check the documentation.  Over time as I gain more experience in more
languages and work with more people's code, I find myself
philosophically leaning more toward the Python mentality of making
everything explicit, but that's another topic for another forum....

--
E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/

Re: completion with globbing, take 2

[Bart Schaefer]

On Sep 18,  6:07pm, E. Jay Berkenbilt wrote:
} Subject: Re: completion with globbing, take 2
}
} >   Does it?  What happens when you complete a pattern that matches only
} >   directories?
} 
} Well, in fact, I never do this with rmdir. [...]
} I really use this with cvs add and cvs rm where it is great.

So you have it restricted by style to :completion::complete:cvs* or
something like that?  I could see where that would be useful, but I
wouldn't want it in context :completion:* ...

I generally do the same thing by using accept-and-menu-complete.  Just
hit tab once, get the first completion, and then hit ^X TAB until all
the files have appeared.  That way I can selectively skip any that I don't
want to add, rather than inserting them all and then having to back up
and delete some.

    bindkey '^X^I' accept-and-menu-complete

} Nice to know.  So I guess zsh functions are like lisp and perl -- the
} value of the last statement is the return value -- but with the
} additional feature that return with no arguments returns the last
} value....

That's true of all Bourne-shell-like shells, actually.  At least, those
that have functions.

-- 
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   

Job Table

[Nick Cross]

Hi,

I'm running 3.1.9 and keep getting job table full messages - how do I
increase the limit?

Cheers,

Nick

RE: completion with globbing, take 2

[Andrej Borsenkow]

>
> More precisely, you were told that Andrej does that.
>

First, I must apologize for wrong advice (you should not answer such questions
at 10pm :-( And I misunderstood the question anyway.

> Andrej probably wasn't expecting you to use it verbatim, though, because
> he didn't show you what his settings for the matcher-list style are.  You
> didn't say whether you have any settings for matcher-list; if you don't,
> the _match completer won't do anything.
>

No, wrong. _match has absolutely nothing to do with matcher-list style (that
was introduced only recently). _match was first "alternative" for
GLOB_COMPLETE option. It tries to match the list of possible completions
against pattern on command line. This works for _every_ completion (while
GLOB_COMPLETE worked only for files). But _match never tries to *expand* the
pattern - that is what _expand is for.

matcher-list is used to set global "matchers" - e.g. to do case-insensitive or
partial-word completion, like completing c-w to complete-word :-)) or g_c to
G_c to globcomplete.

> } I want behavior more like what expand-or-complete does except that I
> } want only what the completion system would return to be substituted.
>

Thinking about it, I believe, that _match would be the correct completer to do
it. There are many cases where we simply cannot do expansion at all - option
names, widget names etc etc etc. So, consider something like

setopt *complete*TAB

WIth _match this enters menu completion - but _expand_word (I tried it) gives
you nothing. So, there seems to be no way to just insert all matching choices.
While _expand (and friends) may be useful at times, _match just seems to be
more powerful. (Of course, another general solution is to have widget that
would insert all listed choices at once. Was not it discussed once?)


> That's what the _expand completer is for.  I believe you want:
>
> zstyle ':completion:*' completer _oldlist _expand _complete _match
> zstyle ':completion::expand:*' completions true
>

Actually, no. It works in this case only because file completion itself is
using globbing - that is, the set of possible matches is determined by pattern
on command line. But the original wish was:

	the * gets replaced with all the choices that the completion system
	returns at that time (i.e., whatever glob pattern I've typed should be
	applied to the completion choices rather than to files)?

It is exactly what _match does ... without giving you the way to insert all
choices.

> And maybe you don't even need the _match on the end, if you haven't
> worked out any matcher-list values yet.  The _match completer is for
> doing things like case-insensitive completion and completion of sub-
> parts of file names (e.g., completing on both sides of a ".").
>

No. See above the description of _match.

-andrej

Re: completion with globbing, take 2

[Sven Wischnowsky]

E. Jay Berkenbilt wrote:

> ...
> 
> _main_complete is called.  It looks up my completers (_oldlist,
> _complete, _expand, and _match) and calls then in order.  _oldlist
> returns nothing, _complete returns nothing (since no files start with
> '*').  Now it starts getting interesting.  _expand is called.  Since I
> have set the completions style for expand to true, it sets
> compstate[insert]=all which gives me the behavior I'm looking for with
> respect to the replacement.  However, since the current context is not
> expand-word:*, it does not call _complete and thus just returns 1.
> Finally, _match is called.  I don't follow exactly what's going on at
> the top of _match, but it doesn't matter.  Since I don't have
> match-original set, _match sets compstate[pattern_match]='*' and calls
> _complete again.  This time, since compstate[pattern_match] is set,
> _complete actually does find matches.
> 
> So the right thing happens, but the path to the desired end seems
> quite convoluted and counterintuitive to me.  I would never have
> figured this out without the significant hints without having to spend
> a lot of time grokking this code.

The first thing is that _expand is intended to be in the completer
list *before* _complete. And it was documented that way.

The other thing is that this kind of use, as you all found out,
doesn't really have anything to do with expansion and hence doesn't
need a pattern on the line -- which lead to _expand being used in
combination with _match and all that.

Hm. Maybe we should make the completer-handling of _expand with the
completions style set more clever. Or something. Probably together
with Bart's changes to _expand_word. I'll have a look.


I'll avoid digging through all the other messages in this thread
again, only one more remark:

Of course, the (implementation of the) completions style is a bit
hackish. And, more importantly, it was never intended to be set
unconditionally. Not too long a go, it was one of the mathematically-
conditional styles (if you don't know what that was, don't mind). 
Nowadays it is intended to be used either with `zstyle -e' (where one
could, inter alia, have a look at the command line with $words,
$BUFFER or $PREFIX (to see if the word is a pattern or some such)) or
with, e.g., _generic, as in:

  zle -C complete-all complete-word _generic
  bindkey '^xa' complete-all
  zstyle ':completion:complete-all:*' completer _expand _complete
  zstyle ':completion:complete-all:*' completions yes



Bye
 Sven


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