From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Sven Wischnowsky <wischnow@berkom.de>, zsh-workers@sunsite.dk
Subject: Re: Test failures in artih and arguments
Date: Wed, 30 Jan 2002 17:37:26 +0000 [thread overview]
Message-ID: <1020130173726.ZM12752@candle.brasslantern.com> (raw)
In-Reply-To: <15447.46235.229244.15033@wischnow.berkom.de>
On Jan 30, 9:53am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
}
} > So it seems to me that we need a wildcard indicator of some kind, so
} > that _arguments can add the match `-<wild>'. This would allow the `-'
} > to be treated as a prefix of the two matches `-x' and `-<wild>'.
}
} Good analysis. And now I'm back at thinking: do we really want that?
}
} If we don't want to be able to complete the options, we would just
} have to add `$PREFIX' or some such as a possible match.
That would work provided that it was added with the equilvalent of
compadd -S '' $PREFIX
so that no space would be added after it.
} Sometimes I think that in such cases we should only force the message
} to be displayed, even if a match was accepted.
Correct me if I'm wrong, but that would result in something like
zsh% foo -<TAB>
zsh% foo -x
Completing arg
(assuming "zstyle :completion:* format 'Completing %d'")
That seems a bit confusing. Or did you mean that, if there was a message
to be forced, then the accepted match would not be completed? That would
be OK, I think.
} And this is also affected by the fake style thing we are discussing
} (which might turn a case of `displaying a message' into `adding some
} matches').
Right, the question becomes how to tell when the message really should
be forced out, and when the faked matches should be used as the possible
completions instead.
Perhaps the thing to do is to treat <wild> as a style context rather than
as a possible match, and determine how to behave based on a style set in
that context.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
next prev parent reply other threads:[~2002-01-30 17:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-23 14:51 Felix Rosencrantz
2002-01-23 16:17 ` Peter Stephenson
2002-01-25 8:58 ` Sven Wischnowsky
2002-01-27 19:20 ` Bart Schaefer
2002-01-30 8:53 ` Sven Wischnowsky
2002-01-30 17:37 ` Bart Schaefer [this message]
2002-02-25 9:14 ` 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=1020130173726.ZM12752@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=wischnow@berkom.de \
--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).