From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22972 invoked from network); 2 Mar 1999 16:53:46 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Mar 1999 16:53:46 -0000 Received: (qmail 14636 invoked by alias); 2 Mar 1999 16:53:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5607 Received: (qmail 14629 invoked from network); 2 Mar 1999 16:53:32 -0000 From: "Andrej Borsenkow" To: "ZSH workers mailing list" Subject: Reading completion manual Date: Tue, 2 Mar 1999 19:52:50 +0300 Message-ID: <000501be64cd$1bc57030$21c9ca95@mowp.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2013.2901 [Not having a car has it's advantages - you can read zsh completion manual on the way home :-)] Some random comments/questions 1. compctl -K parameter I don't like the new convention to make underscore magic. IMHO it is the same hack, as before, but it can possibly cause havoc. Underscore is pretty well established for "private" names, and I expect, that some users really use it in this way (I did at least). That is, define "helper" functions as started with underscore as opposed to "normal" ones that are expected to be called directly. I think, the possible solutions are - use new option character (do we have one free?) - implement long options - (really wild one) implement name spaces. I'd like the last one, but it is probably impossible. A command name may have any character, so there is simply no char that can be (safely) used as delimiter. So, long options is probably the only viable solution. And quite useful in other places as well. It may be useful to interpret return code from such a function (a lá -t). Consider: compctl -T -K _default _default () { case $compstate[context] in redirect ) do redirect completion return 1 # stop any more processing ;; ... esac return 0 # do normal comcptl command/argument completion } This is easy way to add hooks for new extended stuff that compctl cannot handle. 2. PREFIX, IPREFIX, SUFFIX I'd like to have some way to atomically modify them. What I mean is, I'd expect it to be a common source of errors, when somebody modifies IPREFIX but forgets to modify PREFIX (or does it incorrectly). So, some command, that could be used to remove string from PREFIX *and* add it to IPREFIX as atomic operation is quite usable. I understand, that one may want to modify them independently, but this should be really unusual cases. How *PERFIX and SUFFIX are related to words[$CURRENT]? When I modify PREFIX, does it change current word? Other way round? Or are they "read-only" (with exception of IPREFIX<->PREFIX relation)? Do I understand correctly, that PREFIX/SUFFIX respect COMPLETE_IN_WORD? That should probably be explicitly mentioned. 3. compgen I never used explanation myself, but still ... What happens, if I use several compgen's with different explanation strings? What happens, if I use several compgen's with different listings (-y parameter)? Are they merged? If yes, how? 4. compadd It's impossible to understand (based on manual) how -P, -p -i actually work (the same for suffixes). This definitely needs not only better description, but some examples as well. And how it all plays together with -W? Do I understand correctly, that normally compadd only adds strings if they match command line? It is implied, but is not stated explicitly. 5. compcall As I vaguelly remember, compcall now returns result codes? Is it correct? Applied to all three: what about some return code to indicate, if some matches were added? Currently one has to save, and then compare, compstate[nmatches], that looks somewhat ugly. Using return code would provide for compgen -k friends || compgen -u Looks better for me. Probably, this idea could be used for all helper functions as well - is it useful? 6. Conditions As most of us, I don't like the idea of conditions with side effects. But I don't like the Sven's suggestion of replacing conditions with shell code either (at least, with *THIS* code :-) Even more, as it does not solve the original problem - you still have to save parameters and restore them after that. I'd suggest something in between - conditions set special parameters (elements of hash?) that can be used to extract matched substrings/words. That is almost the same, as Sven's suggestion, but probably more user-friendly :) something like if [[ -between string1 string2 ]]; then local -a nwords nwords=(words[$FIRST,$LAST]) ... There is no way to say "from here to eternity", you are forced to set ``end'' to some silly large value. What about using literal string "end" as possible value for ``end''? Description of -nmatches and -matcher still use NMATCHES and MATCHER. Is it correct? cheers /andrej