Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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[-]'
  then
    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'.
    end
  fi    
end

command xterm do       # `command' is for normal compctls
  if cur_prefix = -
  then
    group options do
      strings 132 title
    end 
  else                 # this is anything before a `-x'
    group files do
      strings -frob
      files            # `files' without following strings is `-f'
    end
  fi
end

command xdvi do
  paths                # this is `-/'
  files *.dvi          # `files' with strings is `-g ...'
end

command foo do
  if cur[-1] = -f ||        # this is `-x "c[-1,-f], C[-1,-*f*]"'
     cur[-1] ~ -*f*   
  then
     files; string foo bar  # `flags' can be separated by `;' or newlines

  elif word[1] = -s && pos >= 3  # this is `- "w[1,-s] p[3,-1]"'
  then
     xor                    # there is also `or' for `-t+ +'
       files *.s
       files *.S            # implicitly joining flags, either by
                            # combining their arguments or with `-t+ +'
     xor
       files
     rox                    # ending `xor'
  fi
end

... 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
the example).

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?


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx