From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: Re: expansion
Date: Thu, 15 Jun 2000 10:26:38 +0200 (MET DST) [thread overview]
Message-ID: <200006150826.KAA05864@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Oliver Kiddle's message of Wed, 14 Jun 2000 17:07:59 +0100
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
next reply other threads:[~2000-06-15 8:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-15 8:26 Sven Wischnowsky [this message]
2000-06-15 9:13 ` Bart Schaefer
2000-06-15 9:22 ` Peter Stephenson
2000-06-15 14:54 ` Oliver Kiddle
-- strict thread matches above, loose matches on Subject: below --
2000-06-16 11:22 Sven Wischnowsky
2000-06-16 12:20 ` Peter Stephenson
2000-06-16 7:30 Sven Wischnowsky
2000-06-15 15:15 Sven Wischnowsky
2000-06-15 15:32 ` Bart Schaefer
2000-06-15 9:40 Sven Wischnowsky
2000-06-15 9:09 Sven Wischnowsky
2000-06-14 16:07 Oliver Kiddle
2000-06-14 18:34 ` Peter Stephenson
2000-06-08 8:37 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=200006150826.KAA05864@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--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).