From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-11913-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 18243 invoked from network); 15 Jun 2000 08:26:52 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 15 Jun 2000 08:26:52 -0000
Received: (qmail 14524 invoked by alias); 15 Jun 2000 08:26:41 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 11913
Received: (qmail 14517 invoked from network); 15 Jun 2000 08:26:41 -0000
Date: Thu, 15 Jun 2000 10:26:38 +0200 (MET DST)
Message-Id: <200006150826.KAA05864@beta.informatik.hu-berlin.de>
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
In-reply-to: Oliver Kiddle's message of Wed, 14 Jun 2000 17:07:59 +0100
Subject: Re: PATCH: Re: expansion


Oliver Kiddle wrote:

> ...
> 
> There was one minor problem though.
> 
> > - With `suffix', expansion is not done if there is anything after a
> >   `~foo' or `$foo'. I.e. it will not expand `~foo/<TAB>', but it will
> >   expand `~foo'.
> 
> This doesn't work with arrays: they are never expanded. If I do
> cd $fpath[17]<tab> the directory from my fpath should be expanded. I
> have fixed this in the patch below.

Yes, I think I said that the patterns could do with a little improvement.

> With `suffix', variables mixed with globs (e.g $f/*<tab>) will not do
> glob expansion. This will not bother me a huge amount because I just
> have to remember to expand the variable before I put the glob part in
> but I'll maybe look at extending subst-globs-only to handle this
> situation as well.
> 
> Other people may want more control over when $( ... ) and math stuff is
> expanded (such as the suffix style functionality). I wouldn't for the
> $( ... ) stuff because we can't guarantee that the command produces the
> same output always so completion can't continue after one without
> expansion. I don't use $(( ... )) often enough to really care whether it
> expands though I'd probably prefer the suffix style behaviour.

Hmhm, I think I'll play with it some more, too.

> I'm now back to using _expand so I may come across other issues which I
> haven't thought of at the moment. I'll let you know if I think of
> anything.

Thanks.

> >   We were using rexexact in the old expansion code, so I thought we
> >   should just use `accept-exact' which is the style equivalent of
> >   recexact.
> >   Note that I've used the same default value in _expand as it has
> >   elsewhere (`false'), which means that without further configuring,
> >   this now behaves differently. Should we make it default to `true' in 
> >   _expand?
> 
> Wouldn't it maybe be a good idea if the value of the recexact option
> was used to determine the default for accept-exact so by just setting
> the option, it would have an effect throughout the new completion
> system. There would then always be the option of setting it to a
> different value for a context with zstyle. I would also be inclined to
> rename the style to recexact and negate its meaning for consistency
> with the option.

1) Ah, for completion it already uses recexact as the default (without 
   doing something for it, actually). Only _expand has to handle it
   directly. I didn't think about using [[ -o recexact ]] or some
   such, I'll have a look.
2) Not using `recexact' as the style name was, of course, intentional,
   because it really isn't about `recognising', is it? It's about
   accepting the exact match (it will always take an exact match as
   one of the possible matches[1]).
   And accept-exact has the same meaning as recexact, we don't need to 
   reverse it.

> I've never been convinced that it is wise that without any styles set,
> _expand effectively does nothing: it will inevitably be the source of
> an FAQ. I would have thought that it would be best if by default it
> behaves in the way which most closely resembles expand-or-complete: so
> I would set suffix, glob and substitute by default.

And that from the guy who turned off _expand because it caused him
trouble? ;-)

I did that because before, _expand simply did too much harm to your
command line string. With all the new styles I would prefer to change
the default to be least aggressive but do expansion, but before...

I didn't change that even now because I've regretted these
`mathematically conditional' styles for quite some time now. They
should be turned into boolean styles and the condition should come
from somewhere else, e.g. the -e option to zstyle I suggested (see
11691).


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de