From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23823 invoked from network); 17 Sep 2000 23:34:32 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Sep 2000 23:34:32 -0000 Received: (qmail 8335 invoked by alias); 17 Sep 2000 23:33:49 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12826 Received: (qmail 8328 invoked from network); 17 Sep 2000 23:33:48 -0000 Date: Sun, 17 Sep 2000 19:33:49 -0400 Message-Id: <200009172333.TAA07969@soup.ql.org> X-Authentication-Warning: soup.ql.org: ejb set sender to ejb@ql.org using -f From: "E. Jay Berkenbilt" To: zsh-workers@sunsite.auc.dk Subject: generals observations about completion system Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII As I've been playing in some depth with the completion system lately, I've had a few general observations which I'd like to make. The new completion system seems very powerful and highly configurable at the low level. This is a really nice feature -- one that I am quickly becoming quite addicted to. However, I suspect most users will probably not customize it too much or write too many of their own completion functions, and, based on the manual, I suspect the authors share this belief. So that means that it would be good if the "standard" completion functions, i.e., those installed by default, were easily customizable by users. The primary way in which this is achieved seems to be through styles. The zsh documentation, which seems to be well written and far ahead of the documentation with most systems, it naturally is still somewhat incomplete about how specific completion functions can be customized through styles. Also, it is up to the individual function to support styles. I will give a few specific examples of what I'm talking about. 1. I have been a Kerberos user for some time. I like to have the Kerberos and non-Kerberos versions of the r* commands in my path. Sometimes I call them krlogin, krsh, etc. instead of rlogin, rsh, etc. I wanted zsh to use rlogin's completion rules for krlogin, rsh's rules for krsh, and rcp's rules for krcp. My first attempt at doing this was to say compdef -a _rlogin krlogin krsh rcp This, however, did not work because the code in the _rlogin function hard-codes the names of the commands and uses them in conditions to decide what specific behavior to use. It seems to me that it would have been better to have three separate completion functions here that can share common functions to avoid this. The way I worked around this was to define my own completion function called _krlogin which looks like this: #compdef krlogin krsh krcp # The _rlogin function is conditional on words[1], so we have to # fake it out to make it work. if [[ $words[1] == /* ]]; then words[1]=${words[1]:h}/${${words[1]:t}/#k/} else words[1]=${words[1]/#k/} fi _rlogin 2. The ssh completion function does not use the user-hosts style even though this style is documented. (If it uses it, I've missed it.) It knows about ssh's ability to say ssh user@host rather than ssh host -l user. You can easily override the list of hosts to be completed by setting the hosts style for the ssh command, but this doesn't entirely solve the problem. If I hit ssh TAB I get a list of all users and hosts. There are a lot more users on my system than there are hosts that I ssh to. I want to change ssh to complete only on hosts, not on users. If I want users, I'll use -l. There seems to be no good way to do this without simply copying and modifying the _ssh file. Now I can mitigate this somewhat by saying zstyle ':completion:*:*:ssh:*' users ejb but this doesn't entirely work either. If the first character that I type doesn't match any users, then the completion system falls back to matching against all users. I haven't figured out why whether I can do anything about this. 3. Sometimes I think it would be nice to have an "advice"-like capability (as in lisp). That way it would be easier to write wrappers for things. I'm not sure this is really a good idea.... I don't know enough about how bindings work in zsh to really have a strong opinion.... 4. It's very hard to know what features are documented reliable parts of the interface and what parts aren't. I could change the behavior of the ssh completion function by redefining some of its internally defined functions, but that would be evil and I would probably find that that would stop working in a future release. On the other hand, I feel like a lot of what I'm learning about zsh is just from reading the code, and the danger there of course is that I may accidentally rely on an internal private part of an interface. Certainly the guideline that things that start with _ are not intended to be called directly by users is a start, but then what about things like my workaround for krlogin? Anyway, I understand that I'm using a development release of an experimental version of zsh, so these aren't intended as complaints or criticisms but more as comments or questions. Perhaps a lot of this has already been discussed. All this said, I love using zsh and think it's a great program, wrinkles and all! -- E. Jay Berkenbilt (ejb@ql.org) | http://www.ql.org/q/