From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.dk
Subject: Re: PATCH: Re: Backticks and other tricks
Date: Thu, 29 Mar 2001 16:09:45 +0200 (MET DST) [thread overview]
Message-ID: <200103291409.QAA20643@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Thu, 29 Mar 2001 08:47:11 +0000
Bart Schaefer wrote:
> On Mar 29, 10:14am, Sven Wischnowsky wrote:
> }
> } The only case where the patch would cause trouble is that there are
> } two (or more) options, one being a prefix of the other and the
> } prefixish one gets an argument that has to come directly after the
> } option. A *very* seldom case I would say.
>
> The only thing that worries me, given this explanation, is clusters of
> single-letter options, like some of the very specialized cases in _rpm.
> A whole lot of work went into making those cluster in just about every
> ordering that might make sense to rpm, and some of them are pretty odd;
> for example, -i means something different when it's the first option on
> the line than it does when it follows -q, so `rpm -iq...' completes
> differently from `rpm -qi...'.
I've been thinking about this all day. How is this different from the
situation I wanted to fix with the change? The problem there was that
after a ->state action for an argument in the same word as the option
was used, the option itself was added as a possible completion.
In functions like _rpm, where we have to handle multiple single-letter
options in the same word and probably `nested' calls to _arguments the
situation is the same. If _arguments has found out that we are after
an option whose argument has to come exactly at the point where the
cursor is, in the same word (I seem to be repeating this a lot, but
that's the whole point), then we are in a place where no other option
can be needed anyway (from the program for which we are completing).
And if we are after a single-letter option after which options of some
sub-command have to be completed this is exactly the same as if there
were an option with a argument (and it's written like that in
functions like _rpm). And note that the action will still be taken
(i.e. reported to the calling function), it's just that no more
options of the upper-level call to _arguments will be completed at
that position. And that should be logically correct, because after
the sub-command-like-option only the options for the sub-command are
to be completed which will be handled by the action.
Or maybe I'm just getting blind...
> It doesn't *appear* that anything has gone wrong with it, but there are
> so many possible combinations to try ...
Yes.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2001-03-29 14:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-29 14:09 Sven Wischnowsky [this message]
2001-03-29 16:43 ` Bart Schaefer
-- strict thread matches above, loose matches on Subject: below --
2001-03-29 8:14 Sven Wischnowsky
2001-03-29 8:47 ` Bart Schaefer
2001-03-28 9:49 Sven Wischnowsky
2001-03-28 15:20 ` Oliver Kiddle
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=200103291409.QAA20643@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.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).