zsh-workers
 help / color / mirror / code / Atom feed
From: "E. Jay Berkenbilt" <ejb@ql.org>
To: zsh-workers@sunsite.auc.dk
Subject: generals observations about completion system
Date: Sun, 17 Sep 2000 19:33:49 -0400	[thread overview]
Message-ID: <200009172333.TAA07969@soup.ql.org> (raw)


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/


             reply	other threads:[~2000-09-17 23:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-17 23:33 E. Jay Berkenbilt [this message]
2000-09-19  4:59 ` Bart Schaefer
2000-09-19  9:04   ` Peter Stephenson
2000-09-19 15:19     ` Bart Schaefer
2000-09-19 15:51       ` Clint Adams
2000-09-20 14:33     ` Thoughts on self-documenting functions Bart Schaefer
2000-10-04 11:44 generals observations about completion system Sven Wischnowsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200009172333.TAA07969@soup.ql.org \
    --to=ejb@ql.org \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).