From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6225 invoked from network); 26 Sep 1999 23:28:30 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Sep 1999 23:28:30 -0000 Received: (qmail 22669 invoked by alias); 26 Sep 1999 23:28:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8060 Received: (qmail 22658 invoked from network); 26 Sep 1999 23:28:10 -0000 Date: Mon, 27 Sep 1999 00:28:09 +0100 From: Adam Spiers To: zsh workers mailing list Subject: Re: PATCH: improvement to user@host completions Message-ID: <19990927002809.B5006@thelonious.new.ox.ac.uk> Reply-To: Adam Spiers Mail-Followup-To: zsh workers mailing list References: <19990926151723.F1246@thelonious.new.ox.ac.uk> <9909261502.AA30070@ibmth.df.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <9909261502.AA30070@ibmth.df.unipi.it> X-URL: http://www.new.ox.ac.uk/~adam/ X-OS: Linux 2.2.9 i686 Peter Stephenson (pws@ibmth.df.unipi.it) wrote: > Adam Spiers wrote: > > This patch harnesses the power of Tanaka's _combination in _rlogin, _ssh > > and other functions. > > This is an excellent idea, but it could do with some documentation. Yes, sorry; I've been a bit slack about documentation :-) Problem is, I'm spending way more time on just the coding than I should be, let alone anything else ... Documentation for these will follow when the appropriate tuits present themselves, and I'll document new stuff as it comes, which is the best way of doing things anyway. > Currently that just means comments in the appropriate functions. (Not all > functions have them, of course, but here it's crucial that users know > they're supposed to set some variables.) There's also the `Completion System Configuration' section of the info pages. Is it a deliberate choice that descriptions of most of the standard completion functions (e.g. _dirs, _users, _groups) are missing from the info pages? If not, should they go in the `Utility Functions' section, or maybe in a new section immediately following it? > Ideally, the functions _ssh_users > and _ssh_hosts should be tested for existence before they're defined > so that users can define their own. Nice idea. I'll try to get around to that too. > There were some typos which I've fixed. I really need to stop this late night coding :-( > However (long digresion), in the long run I'm hoping for some > context-sensitive help. Something like _description would be used to add > it. It would give a message something like this (I've assumed my > suggestion for tags and locators, but it doesn't have to depend on that at > all): > > % tar xvzf ^X^H > Current completion context is _tar->tar-archive. > _tar performs completion for the tar command, including GNU tar extension. > Possible subcontexts are: > option, tarfile, content, file > Subcontext tar-archive completes a tar archive. By default this > is a file ending in *.tar, although this can be modified by the GNU -z > option to search for *.tar.gz. > Tags used: > glob: use specific pattern to find a file > path: directory path to a file > anyfile: use any file as default if glob tag fails. > > or in this case > > % ssh ^X^H > Current completion context is _ssh->userhost. > _ssh performs completion for ssh and related commands such as scp. > Possible subcontexts are: > option forward command userhost > Subcontext userhost completes either hostnames, or user@host pairs. > For this to work best the arrays my_accounts and other_accounts > should be set; each contains entries in the form user:[host] where > host defaults to the current host, or {user1,user2}:host for > multiple users on the same host. You may also set _accounts > for each specific such as ssh. > Tags used: > userat: complete username for the form user@host > host: complete an Internet hostname. > > I've simplified this because in fact there is a separate function > _tar_archive, and I haven't worked out how that fits in to this scheme. To > remind you: my idea about tags (and Sven was no doubt thinking along > similar lines) was that they could allow you to set priorities for > completions, e.g. you could say you only wanted user@ to be completed if > all the hosts failed. Then you could extend the tags to set priorities for > my_accounts and other_accounts. There could also be an option so that > typing ^D multiple times toggles between showing the completion list and > showing the context-sensitive help. This is all Zukunftsmusik. This is all very sweet, albeit somewhat ambitious! I look forward to the day it's implemented. Out of curiosity, has anyone any ideas on what the official release plans are for the near future? 3.1.7 soon, or not? Are there any more big plans for 3.2?