zsh-workers
 help / color / mirror / code / Atom feed
From: "Oliver Kiddle" <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk
Subject: Re: ssh completion problem
Date: Tue, 12 Feb 2002 15:08:05 +0000 (GMT)	[thread overview]
Message-ID: <20020212150805.94054.qmail@web9302.mail.yahoo.com> (raw)
In-Reply-To: <15465.5565.960990.977033@wischnow.berkom.de>

Sven Wischnowsky wrote:

> >  Needing two tabs is a separate issue which has come up before.

> > It'll be more complicated if l@b is to complete to lll@bbb.com
> > though.
> 
> ...I think we should also do that in those utility functions, where
> it
> is useful, i.e. _user_at_host. At least that was the idea we had at
> the bginning, leading to functions like _sep_parts.

It's easier for _sep_parts though because all it has is an array of
values for each part. I have at home a _sep_parts like function which
takes _alternative like specs so can call things like _user. Without
relying on compadd's -O, I couldn't see how to get it to do this sort
of thing.

> > Where is the right place to add default matches then?
> 
> In the function where the outer loops are, because only there can we

Seems a pity not to allow utility functions to define the default
orders for the things it completes. It reduces the flexibility of
functions in
the inner circle.

> > Having a way to
> > specify a default tag-order would seem the most logical to me.
> 
> I'd like to hear more about this (so that I understand what exactly
> you mean) and how it could solve -- as an example -- the case we are
> discussing here. Maybe you are thinking about something similar and
> have a solution in mind?

Firstly, I should point out that I don't think this is a solution to
the problem. It is just that setting defaults with || is inflexible.

The idea is simple though. _tags looks up tag-order right? So if _tags
takes an option which specifies a default tag-order. This default is
used unless overriden by a tag-order style.

So instead of:
   compadd -a tmp || _hosts
we can do
_tags -o '"my-accounts" "not-my-accounts"' my-accounts not-my-accounts
and then the usual tags loop. A user can then change the default order
with a style. We'd need some care to ensure that matches are all added
to the hosts group with a `host' description (I don't see why they
should be necessary to _requested and friends for the many cases when
you just want to pass down the values set in an outer loop (which you
have in "$@")).

One idea I have for solving the main part of the problem is only doing
a _next_labels loop around final compadd commands. This loop would need
to loop over all labels for every tag for which an _requested is in our
funcstack. It would lose some flexibility such as a tag-order like:
  'hosts:-domain users' 'hosts:-ipaddr ports'
no longer being possible (so there might aswell then be a separate
label-order style) but such tag-orders only currently work if there is
no tag loop nesting. Also, when looking up the ignored-patterns style,
the _comp_ignore array needs to be augmented so it needs to be
implemented as a sort of stack. I think this solution would lack the
fundamental problems though it does have limitations so I'll be doing
some further thinking. 

> Yes, I know how this works ;-) And I also see that this is a wider
> problem (see above). If I had thought this were the solution, I'd
> have committed the patch.

Sorry, I was under the impression that you thought that patch was a
solution once we'd got the description down to _combination.

> > _netscape. There's also a few cases which look like `_requested

> I don't see such a case there. Are you aware that _wanted and
> _requested use _all_labels which implements the labels-loop?

I'd have expected an _requested if around the _next_label prefixes loop
and an _next_labels loop inside the _requested urls if. I thought
_requested only used _all_labels if it got description arguments.

Cheers

Oliver
PS. You may know anyway but with the recent fake style patch (I think
the _wanted -x one) which you haven't commited, I get problems with
descriptions. grep -<tab> for example lists options and descriptions
separately. I haven't tried the very latest patch which has just
arrived in the last few minutes.

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


  reply	other threads:[~2002-02-12 15:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1020205170847.ZM29675@candle.brasslantern.com>
2002-02-06  9:00 ` Oliver Kiddle
2002-02-07  1:54   ` Bart Schaefer
2002-02-08  9:40     ` Oliver Kiddle
2002-02-08 18:26       ` Bart Schaefer
2002-02-11  9:12       ` Sven Wischnowsky
2002-02-11 18:04         ` Bart Schaefer
2002-02-12  9:18         ` Oliver Kiddle
2002-02-12 13:16           ` Sven Wischnowsky
2002-02-12 15:08             ` Oliver Kiddle [this message]
2002-02-12 15:20               ` Sven Wischnowsky
2002-02-15 17:15                 ` Oliver Kiddle
2002-02-18 14:28                 ` 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=20020212150805.94054.qmail@web9302.mail.yahoo.com \
    --to=okiddle@yahoo.co.uk \
    --cc=zsh-workers@sunsite.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).