From: Tanaka Akira <akr@m17n.org>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: Re: sudo completion problem
Date: 04 May 2000 21:02:06 +0900 [thread overview]
Message-ID: <hvowvlaplq9.fsf@serein.m17n.org> (raw)
In-Reply-To: <000601bfb599$a9219f80$21c9ca95@mow.siemens.ru> (Andrej Borsenkow's message of "Thu, 4 May 2000 11:23:36 +0400")
In article <000601bfb599$a9219f80$21c9ca95@mow.siemens.ru>,
"Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru> writes:
> So, the question is - how useful would it be to allow "named,
> structured, ..." arguments? The point is, description vs. shell code.
> Basically, be able to treat arguments in almost the same way as
> options - with some separator in between. In this case, we could still
> use _arguments for find - actually, it does it quite well currently, and
> it is a pity to reinvent the wheel.
Although I think (-) is good extension, I agree that there are
commands which has too complex argument parsing routine to handle by
_arguments. And it is true that writing dedicated handling routine as
shell function is too difficult in general.
We need intermediate solution for a completion function of such
commands: more powerful than _arguments and easier than shell
function. But more difficult than _arguments, maybe.
My idea is already implemented: _regex_arguments. Although currently
there are only three completion functions - _apt, _xwit and _xset -
which use _regex_arguments because it cannot use _arguments, I think
there are more completion functions which can be written bit more
simple if _regex_arguments is used. Maybe, _xauth (and _cvs?).
> I understand, that this is hierarchical structure that probably cannot
> be handled with one single table ... but, just as idea, imagine that
> action for `update' argument simply points to subarguments description
> ... or something like this ... this may be more readable than shell
> functions. May be not. But it is easier in cases, where we need several
> versions for different plattforms.
In _regex_arguments, a arguments of commands are described as regex
like notation. Of course, it can handle hierarchical one.
> Then I realised, that reverse situation exists with options - there is
> no way to describe options without - prefix. Consider dd or tar ("tar"
> not "GNU tar" :-), BSD ps ... In case of dd we have only options; in
> case of tar ot ps, the first word consists of single letter options with
> possible arguments in next words in order. There is no way to describe
> both case with _arguments (unless I'm mistaken).
_regex_arguments doesn't handle `-' or `+' specially.
> And I'd like repeat once more - currently, when _arguments is using
> lexical structure to describe semantic, it is hard to add something. If
> we had flags ... (not suggesting breaking compatibility - but just for
> future use).
_regex_arguments handle only parsing of arguments. So other stuff
handled by _arguments such as descriptions, exclusive options must be
implemented by completion function writer. It's bit hard task but we
can implement special feature easily.
--
Tanaka Akira
next prev parent reply other threads:[~2000-05-04 12:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-03 14:42 Sven Wischnowsky
2000-05-03 14:56 ` Andrej Borsenkow
2000-05-03 15:09 ` Zefram
2000-05-04 7:23 ` Andrej Borsenkow
2000-05-04 12:02 ` Tanaka Akira [this message]
2000-05-04 13:40 ` Sven Wischnowsky
2000-05-04 15:14 ` Completing for "find" and _regex_arguments (Re: PATCH: Re: sudo completion problem) Bart Schaefer
2000-05-04 16:16 ` Tanaka Akira
2000-05-04 20:12 ` PATCH: Re: sudo completion problem Tanaka Akira
2000-05-04 20:40 ` Tanaka Akira
2000-05-06 6:56 ` Andrej Borsenkow
2000-05-06 7:40 ` Tanaka Akira
2000-05-06 7:51 ` Andrej Borsenkow
2000-05-06 8:19 ` Zefram
2000-05-04 8:03 Sven Wischnowsky
2000-05-08 9:00 Sven Wischnowsky
2000-05-08 15:25 ` Tanaka Akira
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=hvowvlaplq9.fsf@serein.m17n.org \
--to=akr@m17n.org \
--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).