Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: completion with globbing, take 2
- X-seq: zsh-users 3438
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxxxxxx
- Subject: Re: completion with globbing, take 2
- Date: Mon, 18 Sep 2000 17:28:39 +0000
- Mailing-list: contact zsh-users-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <200009171750.NAA05647@xxxxxxxxxxx> <1000917184320.ZM19505@xxxxxxxxxxxxxxxxxxxxxxx> <200009172303.TAA07756@xxxxxxxxxxx> <200009180017.UAA08871@xxxxxxxxxxx> <000001c02136$b9c1f2a0$21c9ca95@xxxxxxxxxxxxxx> <000701c0213d$2434b6d0$21c9ca95@xxxxxxxxxxxxxx> <000001c02157$2ceaa360$21c9ca95@xxxxxxxxxxxxxx>
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author