zsh-workers
 help / color / mirror / code / Atom feed
From: Adam Spiers <adam@thelonious.new.ox.ac.uk>
To: zsh workers mailing list <zsh-workers@sunsite.auc.dk>
Subject: Re: PATCH: improvement to user@host completions
Date: Mon, 27 Sep 1999 00:28:09 +0100	[thread overview]
Message-ID: <19990927002809.B5006@thelonious.new.ox.ac.uk> (raw)
In-Reply-To: <9909261502.AA30070@ibmth.df.unipi.it>

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.

<groan of embarrassment>  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 <cmd>_accounts
>   for each specific <cmd> 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?


  parent reply	other threads:[~1999-09-26 23:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-26 14:17 Adam Spiers
1999-09-26 15:02 ` Peter Stephenson
1999-09-26 16:57   ` Bart Schaefer
1999-09-26 23:28   ` Adam Spiers [this message]
1999-09-26 17:29 ` CVS and patch (again; Re: PATCH: improvement to user@host completions) Bart Schaefer
1999-09-27  7:54 ` PATCH: improvement to user@host completions Tanaka Akira
1999-09-27 13:24   ` PATCH: missing _user@host Adam Spiers
1999-09-27 14:43     ` Ollivier Robert
1999-09-27 15:58       ` Ollivier Robert
1999-09-29 18:56         ` Adam Spiers
1999-10-11 11:22 PATCH: improvement to user@host completions 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=19990927002809.B5006@thelonious.new.ox.ac.uk \
    --to=adam@thelonious.new.ox.ac.uk \
    --cc=adam@spiers.net \
    --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).