Zsh Mailing List Archive
Messages sorted by:
Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)
- X-seq: zsh-workers 4328
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)
- Date: Wed, 19 Aug 1998 11:54:19 +0200 (MET DST)
- In-reply-to: Bruce Stephens's message of 07 Aug 1998 14:04:39 +0100
Bruce Stephens wrote:
> Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx> writes:
> > If you meant that the description should be on a somewhat higher
> > level (something like: these options, or these options followed by
> > filenames, than an optional directory-name, then all files), then I
> > would like to agree, but I'm not sure, how easy we can make that
> > (thinking about commands like `find').
> find is an extreme case. Most people (me, for example) want to be
> able to construct completions for fairly simple things like the tar
> example, and some kind of easy way to do that would be useful, I
> think. A Perl script or something that would produce human-readable
> compctl commands from something similar to the syntax you get in
> manpages (in as much as compctl commands are ever human-readable)
> would be ideal.
I know that find is an extreme example, but I think some of the
problems would also appear for easier commands.
I would like to see a description of what people would want to easily
define and how we could turn that unambiguously into a compctl (a
compctl command string or the internal representation).
Also this is a question of personal taste, I think. At least I prefer
a syntax that lets me get the whole power of a command even it is
rather complicated. But compctl may be a bad example for me, since I
probably know to much about the code in zle_tricky.c to be wondering
what to do to get a certain effect.
Anyway, I would like to go in a direction where we have a simpler (and
more readable) form to define completions and than add some syntactic
sugar for the most common cases. Bart suggested a syntax that is
modeled after the normal shell syntax (if I remember and understood
him correctly). I like that idea.
Another question is if this should be implemented in an external
program, in a new module, in the compctl module, or if we should make
this new syntax the default and keep compctl in another module (which
may become obsolete).
Since I wouldn't like to mess with the shell lexer/parser just to add
a new syntax for completion control, I would (as a first step)
implement it as a new builtin that gets some filenames arguments (or
read stdin), reads these files and expects the new syntax there.
Also, we should have some kind of democratic decision about the
syntax. Let me start with a first suggestion:
# Comments, as in the shell.
pattern */X11/* do # `pattern' is for defining pattern compctls
# more than one pattern can be given before
# the `do'
if cur_prefix = - # this is `-x 's[-]'
group options do
strings display name # this is -k '(display name)'
# -tc is implicit, we would need to have something for `do not
# try other compctls'.
command xterm do # `command' is for normal compctls
if cur_prefix = -
group options do
strings 132 title
else # this is anything before a `-x'
group files do
files # `files' without following strings is `-f'
command xdvi do
paths # this is `-/'
files *.dvi # `files' with strings is `-g ...'
command foo do
if cur[-1] = -f || # this is `-x "c[-1,-f], C[-1,-*f*]"'
cur[-1] ~ -*f*
files; string foo bar # `flags' can be separated by `;' or newlines
elif word = -s && pos >= 3 # this is `- "w[1,-s] p[3,-1]"'
xor # there is also `or' for `-t+ +'
files *.S # implicitly joining flags, either by
# combining their arguments or with `-t+ +'
rox # ending `xor'
... and so on.
We would have to agree on the names for the flags and the `-x'-patterns,
the syntax in the tests and which flags should be turned into
something like a construct (like the `group'-thing above) and which
flags should be turned into something like a command (e.g. `files' in
After that we could define shortcuts for some of the more interesting
things, e.g. `after -I do ... end' as a short form of
`if cur[-1] = -I then ...fi'.
So, any comments?
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by: