From: "Bart Schaefer" <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Re: Test failures in artih and arguments
Date: Sun, 27 Jan 2002 19:20:54 +0000 [thread overview]
Message-ID: <1020127192054.ZM9204@candle.brasslantern.com> (raw)
In-Reply-To: <15441.7716.645376.366627@wischnow.berkom.de>
On Jan 25, 9:58am, Sven Wischnowsky wrote:
}
} Felix Rosencrantz wrote:
}
} > ***************
} > *** 1,4 ****
} > ! line: {tst -}{}
} > ! MESSAGE:{arg}
} > ! DESCRIPTION:{option}
} > ! NO:{-x}
} > --- 1 ----
} > ! line: {tst -x }{}
} > Test ./Y03arguments.ztst failed: output differs from expected as shown
}
} Grrrr... that's a result of the fake style patch. Previously, with a
} function containing:
}
} _argument '-x' ':arg:'
}
} doing
}
} foo -<TAB>
}
} didn't insert anything and displayed be message `arg'.
This isn't quite right -- here's 4.0.4:
schaefer[507] zsh -f
aztec% autoload -U compinit
aztec% compinit -D
aztec% compdef _foo foo
aztec% _foo() { _arguments -x :arg: }
aztec% foo -<TAB>
aztec% foo -x
The comptest code sets the `format' style for the `completion:*:messages'
and `completion:*:descriptions' contexts. Only with one of those styles
set is the `x' NOT inserted; without those styles, it's inserted.
It seems to me that the display formatting should not affect what the
possible matches are. Was this really intended to depend on the `format'
style?
} So we now have the problem that in exactly the same case something we
} certainly want to have with faked matches conflicts with the behaviour
} we wanted there previously (or even now, without faked matches).
}
} I'm not sure how to solve this.
The problem really is that `-<something>' is a valid match, for any
arbitrary value of <something>, but of course we can only write code to
add or list matches that we know about in advance, not those that can be
fabricated interactively.
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>'. The
list and menu code would then have to special case any match that has
<wild> in it, omitting it from listings but displaying the description
for it (if there is one).
However, I don't have any good suggestions on how to chose <wild> such
that it is guaranteed not to conflict with any possible real match.
--
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-27 19:21 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 [this message]
2002-01-30 8:53 ` Sven Wischnowsky
2002-01-30 17:37 ` Bart Schaefer
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=1020127192054.ZM9204@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--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).