* completion with globbing, take 2
@ 2000-09-17 17:50 E. Jay Berkenbilt
2000-09-17 18:43 ` Bart Schaefer
0 siblings, 1 reply; 16+ messages in thread
From: E. Jay Berkenbilt @ 2000-09-17 17:50 UTC (permalink / raw)
To: zsh-users
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/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion with globbing, take 2
2000-09-17 17:50 completion with globbing, take 2 E. Jay Berkenbilt
@ 2000-09-17 18:43 ` Bart Schaefer
2000-09-17 23:03 ` E. Jay Berkenbilt
2000-09-18 6:07 ` completion with globbing, take 2 Andrej Borsenkow
0 siblings, 2 replies; 16+ messages in thread
From: Bart Schaefer @ 2000-09-17 18:43 UTC (permalink / raw)
To: E. Jay Berkenbilt, zsh-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion with globbing, take 2
2000-09-17 18:43 ` Bart Schaefer
@ 2000-09-17 23:03 ` E. Jay Berkenbilt
2000-09-18 0:17 ` completion and globbing, part 2 E. Jay Berkenbilt
2000-09-18 6:07 ` completion with globbing, take 2 Andrej Borsenkow
1 sibling, 1 reply; 16+ messages in thread
From: E. Jay Berkenbilt @ 2000-09-17 23:03 UTC (permalink / raw)
To: schaefer; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* completion and globbing, part 2
@ 2000-09-18 0:17 ` E. Jay Berkenbilt
2000-09-18 6:53 ` Andrej Borsenkow
0 siblings, 1 reply; 16+ messages in thread
From: E. Jay Berkenbilt @ 2000-09-18 0:17 UTC (permalink / raw)
To: zsh-users
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/
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion with globbing, take 2
2000-09-17 18:43 ` Bart Schaefer
2000-09-17 23:03 ` E. Jay Berkenbilt
@ 2000-09-18 6:07 ` Andrej Borsenkow
1 sibling, 0 replies; 16+ messages in thread
From: Andrej Borsenkow @ 2000-09-18 6:07 UTC (permalink / raw)
To: Bart Schaefer, E. Jay Berkenbilt, zsh-users
>
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion and globbing, part 2
2000-09-18 0:17 ` completion and globbing, part 2 E. Jay Berkenbilt
@ 2000-09-18 6:53 ` Andrej Borsenkow
2000-09-18 9:59 ` insert-all-matches example " Andrej Borsenkow
0 siblings, 1 reply; 16+ messages in thread
From: Andrej Borsenkow @ 2000-09-18 6:53 UTC (permalink / raw)
To: E. Jay Berkenbilt, zsh-users
>
>
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* insert-all-matches example RE: completion and globbing, part 2
2000-09-18 6:53 ` Andrej Borsenkow
@ 2000-09-18 9:59 ` Andrej Borsenkow
2000-09-18 17:28 ` completion with globbing, take 2 Bart Schaefer
0 siblings, 1 reply; 16+ messages in thread
From: Andrej Borsenkow @ 2000-09-18 9:59 UTC (permalink / raw)
To: E. Jay Berkenbilt, zsh-users
>
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion with globbing, take 2
2000-09-18 9:59 ` insert-all-matches example " Andrej Borsenkow
@ 2000-09-18 17:28 ` Bart Schaefer
2000-09-18 18:08 ` Andrej Borsenkow
2000-09-18 22:07 ` E. Jay Berkenbilt
0 siblings, 2 replies; 16+ messages in thread
From: Bart Schaefer @ 2000-09-18 17:28 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion with globbing, take 2
2000-09-18 17:28 ` completion with globbing, take 2 Bart Schaefer
@ 2000-09-18 18:08 ` Andrej Borsenkow
2000-09-19 2:02 ` Bart Schaefer
2000-09-18 22:07 ` E. Jay Berkenbilt
1 sibling, 1 reply; 16+ messages in thread
From: Andrej Borsenkow @ 2000-09-18 18:08 UTC (permalink / raw)
To: zsh-users
>
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion with globbing, take 2
2000-09-18 17:28 ` completion with globbing, take 2 Bart Schaefer
2000-09-18 18:08 ` Andrej Borsenkow
@ 2000-09-18 22:07 ` E. Jay Berkenbilt
2000-09-19 2:14 ` Bart Schaefer
1 sibling, 1 reply; 16+ messages in thread
From: E. Jay Berkenbilt @ 2000-09-18 22:07 UTC (permalink / raw)
To: schaefer; +Cc: zsh-users
> } 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/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion with globbing, take 2
2000-09-18 18:08 ` Andrej Borsenkow
@ 2000-09-19 2:02 ` Bart Schaefer
2000-09-20 15:06 ` Andrej Borsenkow
0 siblings, 1 reply; 16+ messages in thread
From: Bart Schaefer @ 2000-09-19 2:02 UTC (permalink / raw)
To: Andrej Borsenkow, zsh-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion with globbing, take 2
2000-09-18 22:07 ` E. Jay Berkenbilt
@ 2000-09-19 2:14 ` Bart Schaefer
2001-02-20 9:55 ` Job Table Nick Cross
0 siblings, 1 reply; 16+ messages in thread
From: Bart Schaefer @ 2000-09-19 2:14 UTC (permalink / raw)
To: E. Jay Berkenbilt; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion with globbing, take 2
2000-09-19 2:02 ` Bart Schaefer
@ 2000-09-20 15:06 ` Andrej Borsenkow
2000-09-20 16:12 ` Bart Schaefer
0 siblings, 1 reply; 16+ messages in thread
From: Andrej Borsenkow @ 2000-09-20 15:06 UTC (permalink / raw)
To: zsh-users
> } > 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion with globbing, take 2
2000-09-20 15:06 ` Andrej Borsenkow
@ 2000-09-20 16:12 ` Bart Schaefer
0 siblings, 0 replies; 16+ messages in thread
From: Bart Schaefer @ 2000-09-20 16:12 UTC (permalink / raw)
To: Andrej Borsenkow, zsh-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Job Table
2000-09-19 2:14 ` Bart Schaefer
@ 2001-02-20 9:55 ` Nick Cross
0 siblings, 0 replies; 16+ messages in thread
From: Nick Cross @ 2001-02-20 9:55 UTC (permalink / raw)
To: zsh-users
Hi,
I'm running 3.1.9 and keep getting job table full messages - how do I
increase the limit?
Cheers,
Nick
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Job Table
@ 2001-02-20 10:04 Sven Wischnowsky
0 siblings, 0 replies; 16+ messages in thread
From: Sven Wischnowsky @ 2001-02-20 10:04 UTC (permalink / raw)
To: zsh-users
Nick Cross wrote:
> I'm running 3.1.9 and keep getting job table full messages - how do I
> increase the limit?
Change the setting of MAXJOB in config.h or re-configure using
--enable-max-jobtable-size=<number> (and then re-build the shell).
Hm, do you really need more than 48 jobs? (The default for MAXJOB is
50, two of them are used internally.)
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2001-02-20 10:04 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-17 17:50 completion with globbing, take 2 E. Jay Berkenbilt
2000-09-17 18:43 ` Bart Schaefer
2000-09-17 23:03 ` E. Jay Berkenbilt
2000-09-18 0:17 ` completion and globbing, part 2 E. Jay Berkenbilt
2000-09-18 6:53 ` Andrej Borsenkow
2000-09-18 9:59 ` insert-all-matches example " Andrej Borsenkow
2000-09-18 17:28 ` completion with globbing, take 2 Bart Schaefer
2000-09-18 18:08 ` Andrej Borsenkow
2000-09-19 2:02 ` Bart Schaefer
2000-09-20 15:06 ` Andrej Borsenkow
2000-09-20 16:12 ` Bart Schaefer
2000-09-18 22:07 ` E. Jay Berkenbilt
2000-09-19 2:14 ` Bart Schaefer
2001-02-20 9:55 ` Job Table Nick Cross
2000-09-18 6:07 ` completion with globbing, take 2 Andrej Borsenkow
2001-02-20 10:04 Job Table Sven Wischnowsky
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).