Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: Re: expansion
- X-seq: zsh-workers 11913
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: Re: expansion
- Date: Thu, 15 Jun 2000 10:26:38 +0200 (MET DST)
- In-reply-to: Oliver Kiddle's message of Wed, 14 Jun 2000 17:07:59 +0100
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author